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System features 


This section lists ACD system features in alphabetical order. Where 
applicable, feature names are followed by Basic if the feature is part of ACD 
basic features (ACD-A, package 45) or Advanced if it is part of ACD 
advanced features (ACD-B, package 41). For a list of the features in each 
package, refer to “Document overview” on page 1. 
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ACD Answering Time in Night Service (Advanced) 


With X11 Release 18 and later, ACD Answering Time in Night Service 
enhances Automatic Call Distribution (ACD) Night Service. If Recorded 
Announcement (RAN) is defined as an ACD Night Service, this enhancement 
allows a customer to define a period of time before incoming calls receive the 
recorded announcement; during this period of time, the calls receive ringback 
tone. 


Operating parameters 


There are no feature requirements. 


Feature interactions 


Attendant Extension to Queue 

A call extended by an attendant or a Centralized Service attendant to an ACD 
Night DN receives ringback tone for the customer-defined period of time 
before receiving Night RAN treatment. There is no recall to the attendant 
after a 30-second period. 


First/Second ACD RAN 


If the ACD DN goes into Night Service while First/Second RAN is being 
provided, the incoming call receives ringback tone for the customer-defined 
time at the end of the First/Second RAN announcement, before receiving 
Night RAN treatment. 


Load Management 

A new NRTT command has been made available for Load Management to 
define or change the length of time before callers receive Night RAN. 
However, the NRTT prompt is only available if the International 
Supplementary Features (SUPP) package 131 is equipped. The existing 
POPT prompt has been modified to print the value of delay for the Night 
RAN. If the International Supplementary Features (SUPP) package 131 and 
Automatic Call Distribution Package D (ACDD) package 50 are both 
equipped, the prompt POPT will skip the value of delay for Night RAN. 


MFE/MFC calls 


An incoming call over an MFE or MFC trunk receives ringback tone only 
when MFE or MFC signaling has ended. 
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Feature packaging 
International Supplementary Features (SUPP) package 131. 
Dependencies: Basic Automatic Call Distribution (BACD) package 40; 
Recorded Announcement (RAN) package 7; Make Set Busy (MSB) package 
17, if used to go into Night Service; and Automatic Call Distribution Package 
B (ACDB) package 41, if used to go into Night Service. 

Feature implementation 
LD 23 — Define the length of time before callers receive Night RAN. 


Prompt Response Description 


RAN route number assigned for ACD Night Service. 


Time, in seconds, before callers receive Night RAN. This 
prompt is only available if International Supplementary 
Features (SUPP) package 131 is equipped. 





Feature operation 


No specific operating procedures are required to use this feature. 
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ACD Call Delays 


The Automatic Call Distribution (ACD) Call Delays enhancement introduces 
two new overlay programmable delay timers which are used when Call 
Forcing is activated for an ACD queue. The first delay timer offers an agent 
a few seconds break before having to answer the next call. The second delay 
timer ensures a caller, during forced answer, receives at least one ringback 
cadence before being connected to an agent. 


Operating parameters 


There are no feature requirements. 


Feature interactions 


There are no interactions with other features. 


Feature packaging 


International Supplementary Features (SUPP) package 131; and Basic 
Automatic Call Distribution (BACD) package 40. 
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Feature implementation 


LD 23 — This overlay is modified to accept responses to and print the new 
FADT and FADR prompts if the SUPP package (131) is equipped. 


Modify, create, or print data for each ACD queue: 


Prompt Response Description 
REQ NEW Add new data. 
CHG Change existing data. 
PRT Print data. 
ACD Type of data block: Automatic Call Distribution. 


XX Customer number. 


Automatic Call Distribution Directory Number. 


Call Forcing option. 
Enter YES to enable Call Forcing. 


Force Answer Delay Timer. 


Enter delay time, in increments of one second, between 
calls when Call Forcing is enabled. 


Force Answer Delay timer for Ringback cadence. 


Enter delay time, in increments of one second, before call is 
connected to an agent. 





Printing the ACD data block will include the FADT and FADR prompts and 
their responses. 


Feature operation 


No specific operating procedures are required to use this feature. 


ACD Feature description 


Page 62 of 278 


System features 


ACD Call Priority 


The Automatic Call Distribution (ACD) Call Priority enhancement 
introduces a modification to the way calls transferred by an ACD agent to an 
ACD queue are handled. Prior to the introduction of ACD Call Priority, calls 
which were answered by an ACD agent and transferred to any ACD Directory 
Number (DN) were put at the end of the target queue. With the introduction 
of ACD Call Priority, the system administrator has the ability, via service 
change, to allow calls transferred by an ACD agent to an ACD DN to be put 
in the priority queue, thereby allowing the transferred call to be answered 
prior to the unanswered calls in the target queue. 


Whether or not a call transferred by an ACD agent to another ACD DN is 
given priority treatment is determined by the response to the new ACPQ 
prompt in LD 23. 


When the response to the ACPQ prompt is YES, any calls which have been 
answered by an ACD agent and which have been transferred to any ACD 
queue are given priority treatment. 


Operating parameters 


There are no feature requirements. 


Feature interactions 


There are no interactions with other features. 


Feature packaging 


International Supplementary Features (SUPP) package 131; and Basic 
Automatic Call Distribution (BACD) package 40. 
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Feature implementation 


LD 23 — This overlay is modified to accept responses to and print the new 
ACPQ prompt if the SUPP package (131) is equipped. 


Modify, create, or print data for each ACD queue: 


Prompt Response Description 


REQ CHG, NEW, PRT Request: Modify, create, or print data block. 


TYPE ACD Type of data block: Automatic Call Distribution. 
CUST 0-99 Customer: Customer number to which data block belongs. 


ACDN XXXX Automatic Call Distribution Directory Number. 


ACD Answer Call Priority Queue (denied) allowed. 


Respond with YES to allow, or NO to disallow, calls 
transferred by ACD agents to ACD DNs to be put into the 
priority queue. 





Printing the ACD data block will include the ACPQ prompt and its response. 


Feature operation 


No specific operating procedures are required to use this feature. 
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ACD Call Waiting Thresholds (Advanced) 


The Automatic Call Distribution Call Waiting Thresholds (ACDCWT) 
enhancement allows ACD Calls Waiting Threshold (CWTH), Busy 
Threshold (BYTH), and Overflow Threshold (OVTH) to be defined as a 
percentage based on the number of calls waiting in queue and the number of 
manned (logged in, not in Make Set Busy or Not Ready state) agent positions, 
rather than as a fixed number of calls. 


When the number of ACD calls waiting exceeds a specified threshold, 
subsequent calls to that ACD DN (the source queue) can be diverted to 
another ACD DN (the target queue). 


Three thresholds must be specified for the calls waiting in each ACD DN 
queue. The operating range boundaries defined by the thresholds are as 
follows: light, normal, busy, and overloaded. The three thresholds are: 


Thresholds Operating Range 
1 Calls Waiting Threshold (CWTH)Upper limit of the light range 
2 Busy Threshold (BYTH)Upper limit of the normal range 
3 Overflow Threshold (OVTH)Upper limit of the busy range 
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Whether the ACD Call Waiting Threshold, Busy Threshold, and Overflow 
Threshold are defined as a percentage or number of calls is determined on a 
customer basis by responding to the OPT (option) prompt in LD 15. The 
allowable ACDCWT responses to the OPT prompt are THPD (Threshold 
Percentage Denied) and THPA (Threshold Percentage Allowed). THPD is 
the default. 


The following is an example of the CWTH, BYTH and OVTH being reached 
if the THPA option is selected: 


Number of calls required in queue to reach 
threshold 


CWTH = 100% BYTH = 150% OVTH = 200% 


2 manned ACD 
positions 





4 manned ACD 
positions 











If all ACD positions are unmanned or out-of-service, any call in waiting 
queue will be treated as if OVTH has been exceeded (i.e., the call will 
overflow). 


An agent in Not Ready status is treated as unmanned when the ACD queue 
thresholds are calculated. 


Operating parameters 


There are no feature requirements. 


Feature interactions 


There are no interactions with other features. 


Feature packaging 


International Supplementary Features (SUPP) package 131; Basic Automatic 
Call Distribution (BACD) package 40; and Automatic Call Distribution 
Package B (ACDB) package 41. 
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Feature implementation 


LD 15 — The Customer Data Block service change accepts the options THPD 
and THPA to be defined as a customer option. The usage of the CWTH, 
BYTH, and OVTH thresholds is defined by the option selected. To allow the 
thresholds to be defined as percentages respond to the OPT prompt with 
THPA. To allow the thresholds to be defined as number of calls respond to 
the OPT prompt with THPD. THPD is the default. 


Prompt Response 


REQ NEW 
CHG 


TYPE CDB 
ATT 


CUST XX 


Description 


Add new data. 
Change existing data. 


Customer Data Block. 
Release 21 gate opener. 


Customer number. 


ACD Threshold Percentage Denied. 

ACD Threshold Percentage Allowed. 

When OPT = THPA, ACD CWTH, BYTH, and OVTH are 
defined as percentages of manned agent positions. 





LD 21 — When the Customer Data Block is printed the THPA or THPD 
option is included in the printout. 


Response 
PRT 
CDB 


XX 


Description 


Print data block. 


Type of data block: Customer Data Block. 


Customer number. 
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LD 23 — The values for the ACD thresholds must be redefined by responding 
to the appropriate prompts. 


Response 


Description 


Add new data. 
Change existing data. 
Print data. 


Type of data block: Automatic Call Distribution. 


Customer number. 


Automatic Call Distribution Directory Number: queue to be 
modified. 


Calls Waiting Threshold 
Default is 1. 


If OPT in LD 15 is set to THPA then 0-2047 is the allowable 
range of percentages. 


If OPT in LD 15 is set to THPD then 0-2047 is the allowable 
range of calls. 


Busy Threshold. 
Default is 0. 


If OPT in LD 15 is set to THPA then 0-2047 is the allowable 
range of percentages. 


If OPT in LD 15 is set to THPD then 0-2047 is the allowable 
range of calls. 


Overflow Threshold. 
Default is 2047. 


If OPT in LD 15 is set to THPA then 0-2047 is the allowable 
range of percentages. 


If OPT in LD 15 is set to THPD then 0-2047 is the allowable 
range of calls. 
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Feature operation 


No specific operating procedures are required to use this feature. 
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ACD-CDR Connection Record (Basic) 


The Connection Record option allows the customer to build and maintain a 
call profile that can be automatically transferred from one ACD agent to 
another. 


Refer to Call Detail Recording description and formats (553-263 1-100) for a 
detailed account of the Connection Record option. 
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ACD Dynamic Queue Threshold 


The Automatic Call Distribution (ACD) Dynamic Queue Threshold 
enhancement modifies the way ACD Call Waiting Thresholds are calculated 
when the percentage option is selected. Prior to the introduction of ACD 
Dynamic Queue Threshold enhancement, agents that were in Not Ready 
status were treated as available (manned) when calculating the ACD queue 
thresholds. With the introduction of the ACD Dynamic Queue Threshold 
enhancement, agents in the Not Ready state are treated as unavailable 
(unmanned) when calculating the ACD queue thresholds. 


Operating parameters 


There are no feature requirements. 


Feature interactions 


ACD Call Waiting Threshold 


The Automatic Call Distribution (ACD) Dynamic Queue Threshold 
enhancement modifies the way ACD Call Waiting Thresholds are calculated 
when the percentage option is selected. The ACD Call Waiting Thresholds as 
percentages is selected when the THPA option is selected as the customer 
option (OPT) in LD 15 (This option was introduced for the ACD Calls 
Waiting Threshold feature for Phase 4). 


Feature packaging 


International Supplementary Features (SUPP) package 131; and Basic 
Automatic Call Distribution (BACD) package 40. 


Feature implementation 


No change to existing configuration is required for the Automatic Call 
Distribution Dynamic Queue Threshold feature. 


Feature operation 


No specific operating procedures are required to use this feature. 
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ACD in Night Service 


This enhancement allows calls to an Automatic Call Distribution (ACD) 
Directory Number (DN) in Night Service and in Position Busy to be routed 
to the night DN, rather than being returned to the originating queue. This 
treatment applies even if the ACD DN is in interflow state. This call 
processing is effected by entering “YES” to the Force Night Call Forward 
(FNCF) prompt in LD 23. 


The interflow treatment supplements the overflow treatment in the way that 
excessive ACD call volumes are handled. Incoming ACD calls are 
transferred to the Interflow DN of the target queue if any of the following 
conditions are met: 


— the number of calls to a source queue reaches the overflow threshold 
(OVTH), or 


— the number of calls to target queues designated as overflow queues have 
reached the busy threshold (BYTH). 


Interflow can be invoked manually (by an interflow key), or automatically 
(by selecting the Automatic Interflow option in LD 23). 


The enhanced operation may be explained as follows: ACD1 has ACD2 as its 
night DN. ACD2 is in interflow state (i.e., incoming calls are routed to the 
interflow DN to receive interflow treatment). A call comes in to ACD1. If 
FNCP = YES, the call is routed to the Night DN (which is ACD2 that is in 
interflow state meaning the call receives interflow treatment rather than 
remaining in the ACD1 queue). 


Operating parameters 


This product improvement applies only to the standalone night treatment — it 
does not apply to Network ACD. 


Feature interactions 


There are no interactions with other features. 


Feature packaging 
Basic Automatic Call Distribution (BACD) package 40. 
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Feature implementation 


LD 23 —- Allow/deny incoming calls to be routed to the night DN, even if it is 
in interflow state: 


Prompt Response Description 


(NO), YES Allow (deny) calls to be routed to the night DN. 





Feature operation 


No specific operating procedures are required to use this feature. 


553-2671-110 Standard 5.00 October 1997 


System features Page 73 of 278 


ACD Least Call Queuing (Advanced) 


In normal handling of Automatic Call Distribution (ACD) calls, incoming 
calls are distributed to ACD agents based on a priority of which agent has 
been idle the longest. This ensures that the time spent by the agents in 
answering calls is balanced amongst them. 


In some ACD environments, however, the requirements exists that incoming 
calls be distributed to agents based on the number of answered calls and not 
on the time spent being idle. This is done by dynamically modifying the agent 
priority based on the number of calls that each agent has answered. As a 
result, an agent that has answered the least number of calls is given the highest 
priority. 


The Least Call Queuing feature allows an ACD supervisor to request, from 

the Load Management command RACN, an ACD report showing the number 
of calls that have been answered by each agent starting from the beginning of 
the working day. The supervisor can then modify agent priority as required, 
and send the information back to the Meridian 1. The Meridian 1 then affects 
the call handling according to the requested priority. 


Operating parameters 


The International Supplementary Features (SUPP) package 131, and Basic 
Automatic Call Distribution (BACD) package 40 must be equipped. 


There is no communication protocol between the Meridian | and the PC, so 
that there is no handshaking between the Meridian | and the PC. Also, error 
detection and correction is not provided. 


Feature interactions 


There are no interactions with other features. 


Feature packaging 
Automatic Call Distribution Package B (ACDB) package 41. 


Feature implementation 


No change to existing configuration is required for the MFC Automatic Call 
Distribution Least Call Queuing feature. 
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Feature operation 


No specific operating procedures are required to use this feature. 
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ACD Night Call Forward without Disconnect Supervision 
(Advanced) 


The X11 Release 23 feature, ACD Night Call Forward without Disconnect 
Supervision, allows Central Office (CO) Loop Start trunks terminating to an 
ACD DN to Night Call Forward or Interflow calls to internal or external sets. 


Note: For the ACD Night Call Forward without Disconnect Supervision 
feature, a CO Loop Start trunk refers to any trunk without disconnect 
supervision. 


Call Scenarios 


The following scenarios (Call Scenarios A-G) apply to calls arriving at an 
ACD DN from a CO Loop Start Trunk. 


Call Scenario A 


The following call sequence applies to a call that arrives at an ACD DN from 
a CO Loop Start trunk and is Night Call Forwarded to a local set: 


4 An external party calls an ACD DN via a CO Loop Start trunk. 
5 The call is Night Call Forwarded to the pre-defined local set. 

6 The set answers the call. 
7 


The originator disconnects. The trunks remain busy until the set 
disconnects. 


8 The set disconnects. The trunks become idle. 


Call Scenario B 


The following call sequence applies to a call that arrives at an ACD DN from 
a CO Loop Start trunk and is Night Call Forwarded to an external ACD DN 
via a route that has the Answer and Disconnect supervision prompt (SUPN) 
set to YES in Overlay 14. 


1 An external party calls an ACD DN via a CO Loop Start trunk. 


2  Thecallis Night Call Forwarded to the pre-defined external ACD DN via 
a route. 


3 The agent answers the call. 


4 The agent disconnects. The trunks become idle. 
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Call Scenario C 


The following call sequence applies to a call that arrives at an ACD DN from 
a CO Loop Start trunk and is Night Call Forwarded to a local ACD DN which 
is in the Not Ready state. 


1 An external party calls ACD DN 1 via the CO Loop Start trunk. 


2 The call is Night Call Forwarded to the pre-defined local ACD DN 2 
which is in the Not Ready state. 


3 The caller abandons the call. 


4 The call stays in the ACD DN 2 queue for a couple of seconds and then 
disappears. The trunks become idle. 


Call Scenario D 


The following call sequence applies to a call that arrives at an ACD DN from 
a CO Loop Start trunk and is Night Call Forwarded to an external ACD DN 
with first Recorded Announcement (RAN) defined and the Return Answer 

Supervision by RAN to originator (ASUP) prompt set to YES in Overlay 16. 


1 An external party calls ACD DN 1 via a CO Loop Start trunk. 


2  Thecallis Night Call Forwarded to pre-defined external ACD DN 2 with 
first RAN defined and ASUP set to YES. The caller hears the Recorded 
Announcement. 


3 The caller abandons the call before the ACD DN 2 agent answers. 


4 The trunks remain busy. The call stays in the ACD DN 2 queue until the 
agent answers the call. 


5 The agent disconnects the call. The trunks become idle. 


Call Scenario E 


The following call sequence applies to a call that arrives at an ACD DN from 
a CO Loop Start trunk and is Night Call Forwarded to an external ACD DN 
with first RAN defined and ASUP set to NO. 


1 An external party calls ACD DN 1 via the CO Loop Start trunk. 


2  Thecallis Night Call Forwarded to pre-defined external ACD DN 2 with 
first RAN defined and ASUP set to NO. 
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3 The caller does not hear the Recorded Announcement and abandons the 
call before the ACD DN 2 agent answers. 
4 After a couple of seconds, the call disappears. The trunks become idle. 
Call Scenario F 


The following call sequence applies to a call that arrives at an ACD DN from 
a CO Loop Start trunk and is Night Call Forwarded to an attendant. 


1 An external party calls an ACD DN via a loop start trunk. 
2 The call is Night Call Forwarded to the attendant. 

3 The attendant answers the call. 
4 


The originator disconnects, but the trunks remain busy until the attendant 
disconnects. 


5 The attendant disconnects. The trunks become idle. 


Call Scenario G 

The following scenario applies to a call that arrives at an ACD DN from a CO 
Loop Start trunk and is Night Call Forwarded to a Controlled DN (CDN). 

1 An external party calls an ACD DN via the CO Loop Start trunk. 


2 A callis Night Call Forwarded to a CDN with a script “ROUTE TO a 
set”. 


3 The caller abandons the call before the set answers. 


4 The call continues to ring on the set for a couple of seconds, but then the 
trunks become idle. 


Operating parameters 
A trunk with SUPN set to NO in Overlay 14 should not be used as a 
destination for either a Night Call Forward DN or an Interflow DN. If this is 
the case and the caller abandons the call, the incoming and outgoing trunks 
are locked out. The destination set rings until the abandoned call is answered 
and the set goes on-hook. 
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It is not recommended that RAN be provided to calls from CO Loop Start 
trunks. In the case where RAN is provided to these trunks, the RAN routes 
should have ASUP set to YES, so that the caller hears the Recorded 
Announcement (RAN). However, because Answer Supervision is returned 
when RAN is provided, the trunks hang if not answered by the agent (Refer 
to Call Scenario D). 


An ACD DN should not be Night Call Forwarded to a local set that Call 
Forward No Answers to Meridian Mail. If this is the case and the originator 
presses the Release key to disconnect the call, Meridian Mail waits until it 
times out. The time for the trunks to become idle depends on the Meridian 
Mail timer. If the originator exits “gracefully” from Meridian Mail, the trunks 
immediately become idle. 


A call arrives from a CO Loop Start trunk to an ACD DN that has Call Force 
enabled (FORC = YES in LD 23). The call is force answered to an unattended 
agent set that is not in the Not Ready or Make Set Busy modes. In this case, 
the trunk is hung until the agent returns and disconnects the call, even if the 
caller disconnects. 


Feature interactions 


Call Forward No Answer 

When an ACD DN Night Call Forwards to a local set that Call Forward No 
Answers to Meridian Mail, two scenarios occur depending on how the 
originator answers the call. If the originator presses the Release key to 
disconnect the call, Meridian Mail waits until it times out. The time for the 
trunks to become idle depends on the Meridian Mail timer. If the originator 
exits “gracefully” from Meridian Mail, the trunks immediately become idle. 


Called Party Disconnect Control 

With Automatic Call Distribution without Disconnect Supervision (ADSP) 
package 289 enabled, calls on routes that have Called Party Disconnect 
Control enabled can Night Call Forward. 


Charge Account/Authorization Code (CAB) in Night Mode - Max 6 
If a caller or trunk without disconnect supervision disconnects from a call 
while trying to Night Call Forward, a CAB message is not sent to MAX 6 or 
later. This is because the switch does not know that the caller disconnected. 
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Federal Communication Commission (FCC) Compliance for 
Direct Inward Dialing (DID) Answer Supervision 

If the FCC package 223 is equipped, answer supervision is automatically 
returned to the Central Office when RAN is provided or when the call is 
answered at the remote node. 


Meridian 911 


Meridian 911 (M911) calls always have disconnect supervision. The ACD 
Night Call Forward without Disconnect Supervision feature does not change 
this. 


Meridian Mail 


When an ACD DN Night Call Forwards to an internal/external set that Call 
Forward No Answers to Meridian Mail, two scenarios occur depending on 

how the originator answers the call. If the originator presses the Release key 
to disconnect the call, Meridian Mail waits until it times out. The time for the 
trunks to become idle depends on the Meridian Mail timer. If the originator 
exits “gracefully” from Meridian Mail, the trunks immediately become idle. 


Network Automatic Call Distribution 
Network Automatic Call Distribution (NACD) does not allow a call to 


overflow via the NACD night/day table if the call comes from a trunk without 
disconnect supervision. 
Feature packaging 


The following package is required for ACD Night Call Forward without 
Disconnect Supervision: 


— Automatic Call Distribution without Disconnect Supervision (ADSP) 
package 289, which depends on the following packages: 


e Automatic Call Distribution Package A (ACD-A) package 45 for 
Night Call Forward (NCFW) 


e Automatic Call Distribution Package B (ACD-B) package 41 for 
Interflow DN (IFDN) 


Feature implementation 


Note: All ACD agents and ACD blocks must exist prior to 
implementing this feature. 
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LD 23- Define a Night Call Forward DN for an ACD DN. 


Response Description 


CHG Change existing data. 
ACD Automatic Call Distribution block. 
Customer number. 
Automatic Call Distribution Directory Number. 


ACDN can have a maximum of 4 digits or a maximum of 7 
digits with DNXP package 150. 


Night Call Forward DN for ACD calls. 
With X11 Release 22 and later, the NCFW DN can have a 
maximum of 31 digits. 





LD 14- Define a Night Call Forward Destination trunk. 


Response Description 
Change existing data. 
Trunk type. 


Terminal Number. 


For Option 11C. 


Answer and disconnect supervision required. 
NO = Answer and disconnect supervision not required 
(default). 





Feature operation 


No specific operating procedures are required to use this feature. 
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Alternate Call Answer (Basic) 


Alternate Call Answer (ACA) allows the customer to choose, on a per queue 
basis, whether ACD calls should be blocked for an agent set with an 
Individual Directory Number (IDN) call on hold. 


When Alternate Call Answer is enabled, if an agent notices an ACD call 
waiting through the AWC key or the supervisor terminal while active on an 
IDN call, the agent can put the IDN call on hold and press the dark In-Calls 
key to return to the idle agent queue. The In-Calls key will stay dark until an 
ACD call is presented. 


When Alternate Call Answer is disabled and an agent is active on an IDN call, 
putting that call on hold and pressing the dark In-Calls key does not return the 
agent to the idle agent queue. No ACD calls will be presented. 


Be sure to evaluate operating procedures before enabling this feature. For 
example, ACA should not be used if an agent puts an IDN call on hold and 
walks away. ACD calls could be connected while the agent is gone. 


Feature interactions 


500/2500 ACD sets 
Alternate Call Answer does not support 500/2500 ACD sets. 


Answer/call ACD supervisor 
Answer/call ACD supervisor is supported. The agent can press the Supervisor 
(ASP) key to answer/call the ACD supervisor, if 


— the agent uses the Supervisor key to talk to the ACD supervisor and 


— an ACD call is waiting in the queue 
The Alternate Call Answer option then allows the agent to 


— press the Hold key to put the supervisor call on hold 


— peress the Dark In-Calls key to be ready to answer an incoming ACD call 


Call Transfer 
Call Transfer is supported. The Alternate Call Answer Option allows the 
agent to press the 
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— _ hold key to put the call on hold after the third party answers the call and 
before completing the transfer 
— dark In-Calls key to be ready to answer an incoming ACD call 


Conference 


Both three-party and six-party conferences are supported. The Alternate Call 
Answer feature allows the agent to press the 


— hold key to put the established call on the Conference key on hold 
— dark In-Calls key to be ready to answer an ACD call 


No Hold Conference is not supported. 


Dial Intercom 


Dial Intercom (DIG) is supported. If the agent makes a call using the DIG key 
and an ACD call is waiting in the queue, the Alternate Call Answer option 
allows the agent to press the 


— hold key to put the DIG call on hold 


— dark In-Calls key to be ready to answer an incoming ACD call 


Hot Line 


Hot Line (HOT) is supported. If the agent makes a call using the HOT key 
and an ACD call is waiting in the queue, the Alternate Call Answer option 
allows the agent to press the 


— _ hold key to put the HOT call on hold 


— dark In-Calls key to be ready to answer an incoming ACD call 


Multiple Call Ringing/Non-ringing 

Multiple Call Ringing/Non-ringing (MCR/MCN) is supported. If the agent 
makes a call using the MCR/MCN key and an ACD call is waiting in the 
queue, the Alternate Call Answer option allows the agent to press the 


— hold key to put the MCR/MCN call on hold 


— dark In-Calls key to be ready to answer an incoming ACD call 
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Private Line Ringing/Non-ringing 

Private Line Ringing/Non-ringing (PVR/PVN) is supported. If the agent 
makes a call using the PVR/PVN key and an ACD call is waiting in the queue, 
the Alternate Call Answer option allows the agent to press the 


— hold key to put the PVR/PVN call on hold 
— dark In-Calls key to be ready to answer an incoming ACD call 


Ring Again 

Ring Again (RGA) is supported. 

Single Call Ringing/Non-ringing 

Single Call Ringing/Non-ringing (SCR/SCN) is supported. If the agent makes 


a call using the SCR/SCN key and an ACD call is waiting in the queue, the 
Alternate Call Answer option allows the agent to press the 


— hold key to put the SCR/SCN call on hold 

— dark In-Calls key to be ready to answer an incoming ACD call 

Voice Calling 

Voice Calling (VCC) is supported. If the agent makes a call using the VCC 


key and an ACD call is waiting in the queue, the Alternate Call Answer option 
allows the agent to 


— press the Hold key to put the VCC call on hold 


— press the Dark In-Calls key to be ready to answer an incoming ACD call 


ACD Feature description 


Page 84 of 278 System features 


Automatic Overflow (Advanced) 


Automatic Overflow allows incoming ACD calls to be diverted from the call 
queue in which they would normally be placed (source queue) to another 
queue (target queue) during busy periods. Up to three target queues can be 
designated for each source queue. The target queue that meets the 
requirements for Overflow (the queue is not handling a volume of calls that 
exceeds a predefined busy threshold) is selected as the queue to which 
incoming calls are redirected. Overflow does not occur unless at least one of 
the Overflow queues meets these requirements. The situation is evaluated for 
each new incoming call. 


Automatic Overflow only applies to new calls attempting to enter a queue; 
calls already in the queue are not transferred to a target queue. Priority calls 
that are overflowed to another queue retain their priority status in the target 
queue. The various treatments (such as RAN and Music) specified for the 
source queue remain in effect for each call, even though it is placed in the 
target queue. 


Three threshold levels must be established for each ACD DN involved in 
Automatic Overflow: 


— CWTH = Calls Waiting Threshold 
— BYTH = Busy Threshold 
— OVTH = Overflow Threshold 


The threshold levels are set for each ACD DN during installation and can be 
modified by service change or load management. 


The first threshold (CWTH) is for lamp status only. 


When the second threshold (BYTH) is met or exceeded, the queue is busy. 
This queue cannot accept any calls attempting to overflow from other queues. 


When the third threshold (OVTH) is met or exceeded, the queue is in an 
Overflow state. The next new call into the queue attempts to overflow. 
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Note: For a complete discussion of lamp states, see “Calls Waiting 
Indication key (AWC) (Basic)” on page 25 and “Calls Waiting 
Indication key (AWC) (Advanced)” on page 26, or “Display Waiting 
Calls (DWC) key” on page 28 and “Display Waiting Calls (DWC) key 
(Advanced)” on page 29. 














The system checks the Overflow queues one at a time. The first queue 
operating below the BYTH is selected as the target queue. The call is then 
placed in the target queue and does not return to the source queue. Selection 
of a target queue is performed for each new call coming into the source queue. 
Thus, if a target queue meets or exceeds the BYTH, then another queue is 
checked as a target queue. If an available target queue is not found, the call is 
placed in its source queue. 


Source and target queues must be within the same ACD customer, unless 
Network ACD (NACD) is allowed. NACD uses timed overflow rather than 
automatic overflow. See Network ACD description and operation 

(553-367 1-120). 


A physical telephone must exist and be in the Not Ready state for the 
Automatic Overflow decision process illustrated in Figure 4. 
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Figure 4 
Automatic Overflow decision process 
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Call Forcing (Advanced) 


Call Forcing is an alternative to standard manual answering. This feature 
automatically presents a call to an agent in an answered state. Consequently, 
if the Call Forcing option is enabled, the In-Calls key is not pressed to answer 
the call. 


An ACD call answered by Call Forcing can be completed in one of the 
following ways: 


— Ifthe caller releases and disconnect supervision is provided, the agent is 
returned to the agent queue automatically after a two-second delay. 


— If post-call processing is not required, the agent presses the In-Calls key 
or release key to force a disconnect. The agent is returned automatically 
to the agent queue after a two-second delay. 


— If post-call processing is required, the Not Ready key is operated. When 
post-call work is finished, the In-Calls or Not Ready key is pressed, and 
the agent is inserted immediately into the agent queue. 


Before X11 Release 16, there is a predetermined two-second delay between 
when the agent releases from an ACD call and when the agent is available to 
receive the next ACD call. 


X11 Release 16 and later provides a delay, from 0 to 30 seconds, before 
presenting another call. When an agent disconnects from an ACD call, the 
agent has from 0 to 30 seconds until the next ACD call can be presented based 
on the delay time set in the system software with the FCFT prompt in LD 23. 
The default is two seconds. See the X// input/output guide. 


Feature interactions 

Priority Agent 

Flexible Call Forcing interacts with Priority Agents. If a call comes into a 
queue while the priority 1 agent is still in a delay state (the Flexible Call 
Forcing timer has not expired), the priority 2 agent receives the call. The 
priority 1 agent is not returned to the idle agent queue until the specified time 
is up. 
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ACD Call Delays 


The ACD Call Delays enhancement introduces two new programmable delay 
timers which are used when Call Forcing is activated for an ACD queue. The 
first delay timer ensures that a caller, during forced answer, receives at least 
one ringback cadence before being connected to an agent. This timer is 
configured at the FADR (Force Answer Delay time for Ringback cadence) 
prompt in LD 23. The second delay timer offers an agent a few seconds break 
before having to answer the next call. This delay timer is configured at the 
FADT (Force Answer Delay Time) prompt in LD 23. 


Headset and handset 

Call Forcing can be used with agent telephones equipped with a headset, a 
plug-in handset, or a standard handset. When using either a headset or a plug 
in handset, Call Forcing operates as described. Unplugging the headset or 
handset activates Make Set Busy. When using a telephone with the standard 
handset and switchhook, Call Forcing works only when the handset remains 
off-hook. 
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Call Interflow (Advanced) 


Call Interflow gives the ACD supervisor the ability to redirect excess traffic 
to another predesignated Interflow DN (IFDN). The Interflow (ENI) key 
supplements Automatic Overflow. When the Interflow (ENI) key is pressed, 
the Interflow action occurs only after the following events: 


— the number of calls in the source queue equals or exceeds the Overflow 
Threshold (OVTH) 


— _ all target queues specified for Automatic Overflow are at or past their 
Busy Thresholds (BYTH), or are in Night service 


— the ENI key has been pressed 


The number of calls in the Time Overflow (TOF) queue is added to the 
number of calls in the high-priority and non-priority queues to determine if 
the OVTH or BYTH has been exceeded. 


If the Interflow DN (IFDN) is an internal ACD DN and the source DN has a 
TOF Timer (TOFT) defined, then the call can recall back to the source ACD 
DN. Refer to the sections on Overflow configurations for details on call 
configurations when the IFDN is defined as an internal ACD DN. 


Note: Ifa call routes to an Interflow ACD DN in Night Service, the call 
is rerouted back to the source queue. It does not forward to the Night Call 
Forward (NCFW) DN for the target queue. 


Enhanced Interflow 


Call Interflow is enhanced to provide Interflow mode automatically from 
source queues without using the Enable Interflow (END key. This 
enhancement also monitors calls after evaluating the Interflow destination. If 
a busy condition is encountered, then there are two possible treatments. Only 
one of these treatments is presented to a call: 


— Busy Tone Returned 
— Link to the Source Queue 


Calls from high-priority trunks are put in the high-priority queue. All other 
calls are put in the non-priority queue. Once in a queue, calls are allowed to 
receive RAN, music, and other options as defined for the source queue. 
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Enhanced Interflow operates in three steps. As long as the Interflow DN 
(IFDN) for the source queue is another ACD DN, the system can send 
Interflow calls to another queue for a total of three ACD DNs. However, if all 
three IFDNs are in the Night mode or Interflow state, the call is placed in the 
source queue (see Figure 5). 


Respond to the BUSY prompt in LD 23 to treat the following call types: 


Internal 
Attendant 
CO/Trk 
DID/Tie Trk 


Busy or Link to Source is defined for these four call types. CO/trk calls 
always link to source because they cannot return answer supervision. Table 3 
defines the treatments, based on call type, for IFDN destinations available to 
incoming calls. 
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Table 3 


IFDN treatment by Call Type when the IFDN is unavailable 


System features 





Call type (originating) 


























queue 








to source queue 





source queue 





Telephone Attendant CO trunk DID/Tie trunk 
Telephone Busy tone Busy tone, link Link to Busy tone, link 
to source queue | source queue | to source queue 
Attendant Busy tone Link to source Link to Busy tone, link 
queue source queue | to source queue 
ACD DN Busy tone, link Busy tone, link Link to Busy tone, link 
z to source queue | to source queue | source queue | to source queue 
a 
a Trunk Busy tone Busy tone, link Link to Busy tone, link 
ACOD to source queue | source queue | to source queue 
NARS Busy tone Link to source Link to Busy tone, link 
queue source queue | to source queue 
Invalid DN Link to source Busy tone, link Relink to Link to ACD 


source queue 





Feature interactions 


ACD Night Call Forward 
If the Night Call Forward (NCFW) number is another ACD DN in the 


Interflow state, the call is sent by Interflow mode to the next level. If the call 


has already been sent to the third level, it waits until the NCFW DN queue is 
available. When room is available in the queue, the call is placed in the 


NCFW queue. 


ANI route selection 
An Access Code for ANI trunks can be set as an Interflow treatment 


destination. 


Attendant extension 





The attendant can only extend calls to a queue in Interflow when the Interflow 
treatment is linked to the source queue. 
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Attendant Overflow Position 


Calls that are given Interflow or Night Call Forward treatment to an attendant 
can be answered. 


Class of Service restrictions 


If the IFDN is trunk restricted from the call originator, the call is returned to 
the source queue instead of receiving an overflow or busy tone. 


Do Not Disturb (DND) 


If the attendant has activated DND on the IFDN telephone and its Hunt DNs 
are busy, the call receives Interflow treatment as if the IFDN were busy. 


Invalid IFDN 


If the IFDN for the source queue is invalid, error code ERR4277 is output and 
the call is linked back into the source queue. For definitions of the error codes 
that are output, refer to X71 input/output guide. 


Network Ring Again (NRAG) 
If the Interflow treatment defined links calls back to the source queue, the 
NRAG call is not allowed to ring again. 


Automatic Overflow 


A call that is subject to the Interflow treatment, but is returned to the source 
queue instead, cannot be treated with the Automatic Overflow treatment to a 
target ACD DN. 


Ring Again (RGA) 

Internal calls treated with the Interflow treatment from an internal telephone 
are allowed to ring again to the IFDN. If the IFDN is an Attendant in Night 
Service, then the internal telephone can ring again to the IFDN. 


TGAR restrictions 


If the IFDN is subject to TARG/TGAR restrictions, the call is linked to the 
source queue instead of receiving an overflow tone. 


Time Overflow 

A call that has interflowed to another ACD queue can be returned to the 
source queue based on the source queue’s Time Overflow Timer (TOFT). 
The call is eligible to be answered by an agent in the source queue, or the 
target queues specified as Overflow DNs (OVDN). 
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Trunk Group Busy 


If the IFDN is a Route Access Code and all trunks in the route are busy, calls 
transfer to the attendant. If the IFDN is a NARS/BARS access code, and any 
one route is Attendant Busied, calls transfer to the attendant. 


DNIS 


DNIS information is passed to the Interflow destination. 


Operating parameters 
Busy trunk conditions apply only to internal trunks on the same switch as the 
source ACD DN. 


The DNs for DISA calls are not supported by a Call Interflow treatment or its 
enhancements. 


If the programmed IFDN is not an ACD DN, then calls that Interflow cannot 
transfer back to the source queue while it is in interflow state. 


The DN for a Release Link Directory Number (RLDN) is not supported by a 
Call Interflow treatment or its enhancements. 


Note: With ACD DISC SUP PK package, CO loop start trunks 
terminating to an ACD DN are allowed to NCFW or interflow. However, 
avoid the following situations: 


a An ACD DN Night Call Forwards to a local set that Call Forward 
No Answers to Meridian Mail. 

b Night RAN is defined while NCFW = none. 

c Using an external route with SUPN = NO for either NCFW or 


interflow. 


In cases a and b, trunks become hung-up and must be manually disabled 
in LD 32. In case c, if the caller abandons the call, the destination set 
rings until the abandoned call is answered and the set goes on-hook 
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Customer Controlled Routing (CCR) (Advanced) 


In addition to EAR basic functionality, Customer Controlled Routing (CCR) 
allows the customer to customize the treatment and routing of incoming calls 
through a user-friendly interface. Calls arriving at a CDN in the controlled 
mode have their handling determined by a customer-defined script executed 
by the Customer Controlled Routing Module (CCRM) application, rather 
than being handled by the X11 software. Refer to the NTPs listed at the 
beginning of this document for further information. 


Specifying the controlled option for a CDN allows the CCRM application to 
control the call treatment of calls arriving at the CDN. This controlled option 
is called the “controlled mode.” 


The CCR application module allows customers to write call scripts that 
specify call routing to one or more destinations within the Meridian 1 system. 
When a call arrives at a CDN in controlled mode, the X11 software informs 
the CCRM software of this event using communications over an Application 
Module Link (AML) dedicated to the CCR application. 


CCR associates the call with a customer-defined call treatment script, based 
on the CDN where the call arrived. The X11 software receives instructions to 
direct the handling of the call based on the script commands. Customers 
decide how a call is handled based on a variety of parameters, such as CLID, 
DNIS, time of day, number of calls queued at the destination ACD DN, or 
number of idle agents. In addition, CCR allows a call to queue simultaneously 
at up to four ACD DNs. You can also remove calls in queue to ACD DNs with 
the Remove From request. 


CCR requires additional hardware and software packages. CCR requires an 
additional application processing module, the Customer Controlled Routing 
Module (CCRM), in addition to CCR (package 215), EAR (package 214), 
and Command and Status Link (package 77). 


CCR features include all the functionality of EAR features plus the additional 
features covered in this section. Refer to “Enhanced ACD Routing 
(Advanced)” on page 149 for the EAR advanced features. 
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CCR features allow calls arriving through CDNs in the controlled mode to be 
queued in four ACD DNs simultaneously. CCR calls in controlled mode are 
considered virtual calls and are not counted as part of the number of calls in 
queue at an ACD DN for features such as Overflow by Count and Interflow. 
When equipped with CCR, a CDN possesses the following attributes: 


— mode of operation (controlled or default) 


— association with the Application Module Link (AML) handling CCR 
messages for this DN (VSID) 


— association with TTYs assigned for status display 
— CWTH, BYTH, and OVTH thresholds 
The mode of operation of an individual CDN can be switched between 


controlled mode and default mode by changing the mode of operation 
attribute of the CDN. It can be changed by the following: 


— LD 23 

— load management 

As calls arrive at a CDN, the operation mode of the CDN is checked to 
determine the treatment required for the call. If controlled mode is selected, 
the X11 software notifies the CCRM application. If the CCRM software 


accepts the call, it is controlled by the CCRM application. If the conditions 
for controlled treatment are not met, the call is given the default treatment. 


The conditions for meeting the controlled treatment requirements are as 
follows: 


— The CDN must be set to controlled mode. 


— The AML must be defined and operational for communication with the 
CCRM application. 


— TheCCRM application must take control of the call within 4 to 6 seconds 
for most types of calls and 1.9 seconds for Japan DID trunk calls. 
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CCR controlled mode operation 


In controlled mode operation, an arriving call is queued to the CDN until one 
of the following actions occur: 


— The call is answered. 
— The call is abandoned (caller hangs up). 
— The call is given busy or disconnect treatment from CCR. 


— A Route request is performed. 


While it remains in the CDN queue, the only call processing applied to the 
call is that issued by the CCRM application through command messages. 


CCR script commands and operation 


Queue request 


The Queue To request command allows a call to be virtually queued to an 
ACD DN while maintaining its position at other ACD DNs that received a 
Queue To request. A call can be queued to up to four ACD DNs 
simultaneously. 


A priority is specified in the queue request, which determines the call’s 
placement in the ACD DN queue. If a tone has not yet been given to the call, 
the call receives ringback until changed by the CCRM application. 


All subsequent queue requests place the call in the specified ACD queues 
simultaneously, without changing the placement of the call queues where it 
already resides. If a second queue request is attempted for a queue that the call 
is already in, the call is repositioned in the ACD queue with respect to the new 
priority. 


Call priority 
Controlled mode CCR provides four levels (1-4) of call priority. These are 
the call priorities and their corresponding ACD priorities: 


— priority 1: high-priority timed overflow call queue (highest) 
— priority 2: non-priority timed overflow call queue 
— priority 3: high-priority call queue 


— priority 4: non-priority call queue (lowest) 
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Queuing by priority 

When the CCRM application issues a Queue Request, the call for which the 
queue request was made is placed at the end of the ACD priority call queue, 
corresponding to the requested priority. 


By placing a call at the end of its priority, an ordering by time-in-priority is 
maintained. Therefore, calls that have been waiting longer in a specific 
priority are never positioned behind calls just entering the priority. 


Changing call priority 

When the X11 software receives a Queue Request for a call already queued 
at the specified ACD DN, and the priority in the request is different from the 
call’s current priority assignment, the call is repositioned in the ACD queue 
at the end of its new priority. 


If the priority is the same, the request is ignored and the call retains its current 
position and priority in the specified ACD queue. Changing a CCR call’s 
priority in one ACD queue does not affect its priority (which can be different) 
in other ACD queues where it can also be placed. Once a call’s priority has 
been changed, its time-in-priority is zero in the ACD queue for which its 
priority was changed. The call’s time-in-priority in other ACD queues in 
which the call is waiting is not affected. 


Order of presentation of queued calls 

Three different queue priority algorithms can be defined for an ACD queue 
to determine which call in that queue is selected for presentation to an 
available agent. The CCR calls are threaded into the existing queues based on 
the priority the CCR module assigns to it. Therefore, the existing call 
presentation algorithms apply to CCR calls as described in the following 
options. 


Note: The following describes how the existing call presentation 
algorithms apply to ACD DNs, not CDNs. 


Oldest call in network 

This option picks the oldest, highest priority call in the network. The first call 
in the TOF, Call Request, and nodal source TOF queues must be compared. 
The call with the highest priority that has waited the longest is presented to 

the available agent. In LD 23, OCN=Yes and HPQ=NO. 
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Own TOF queue first 


This option picks the oldest, highest priority call within the ACD queue’s 
own TOF queue. In LD 23, OCN=NO and HPQ=NO. 


Own TOF and high-priority queues first 


This option picks calls from the queue’s own TOF and high-priority queues 
before any others. In LD 23, OCN=NO and HPQ=Yes. 


Determining queue length 


Some ACD functions such as Overflow by Count and Interflow operate 
according to the number of calls in the ACD queues. Since the CCR calls are 
virtual calls, they will not be counted when determining the queue length for 
an ACD DN in the following: 


— Overflow Threshold (OVTH), used by Overflow by Count and Interflow 
— Busy Threshold (BYTH), used by Overflow by Count 

— call waiting field on the ACD/Meridian MAX real-time displays 

— ACD-C Ongoing Status Displays 


— Call Waiting lamp updates if the new call waiting option (NCWL) is 
disabled 


— number of calls currently waiting in queue field (aaa) of the DWC 
display 

CCR calls are counted for the following: 

— apart of the total number of queued calls for CCR call scripts 


— the waiting time of the oldest call in the queue field (ccc) of the DWC 
display 


— Call Waiting lamp updates if the new call waiting option (NCWL) is 
enabled 


— the virtual calls that can be answered field (dddd) of the DWC display 


— the age of oldest call intrinsic within CCR call scripts 
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— the number of calls to be answered when an ACD DN enters the 
transition mode of Night Service 


— inthe new ACD-D option, messages that include the number of CCR 
calls for real-time displays 


Remove From Request 

The Remove From Request allows the CCRM application to remove a call 
from a queue where it was previously queued. The removal does not affect 
the placement of the call in other ACD queues. 


A call cannot be removed from a CDN queue. A call can only be removed 
from ACD DNs where a Queue Request was previously issued. 


Give RAN Request 

With a Give RAN Request, the CCRM application can request that a certain 
call be given RAN treatment from the RAN route indicated within the Give 
RAN request. When a RAN Request is received, the call is given the RAN of 
a specified route (if trunks are available), or placed in the RAN queue 
corresponding to that route. 


The RAN route parameters defined on the Meridian | determine the type of 
RAN provided. If different RANs are desired for a call, they must be defined 
in different routes. 


The X11 software cannot connect the call to a route that is not marked for 
RAN by service change. If RAN is given to a call, the next call script 
command is not executed until the RAN message is finished. 


If a call is presented to an agent while receiving RAN, RAN is interrupted, 
ringback is given to the caller, and CCRM is notified of the RAN completion. 
If the agent returns the call to the queue at the time of presentation by pressing 
the Not Ready or Make Set Busy keys, the caller is given ringback. Since the 
call was not answered, the CCRM application continues to control the call 
and issue call control commands for the call. 


An attendant is not allowed to receive RAN treatment. 


If the first command of a call script is Give-RAN, ringback is provided with 
connection to RAN. Because of this, the RAN route is no longer required to 
have answer supervision enabled for an ISDN call to first receive RAN. 
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Music Request 

The Music Request provides music to the caller. The route specified must be 
marked as a music route for the command to succeed. Music is persistent; it 
is given between other call treatments once given to the call. For example, a 
controlled call receiving Music because of a previous request is given RAN 
by a RAN request. After completing the RAN, music resumes. 


An attendant is not allowed to receive music treatment. 


Tone Request 

This request provides the caller with a tone option. Currently, silence and 
ringback are the only supported tones. The tone specified in this command is 
provided to the caller until it is interrupted (replaced by a RAN or Music 
request when the call is presented, forced, or routed elsewhere, or the tone is 
changed by another tone request). 


The treatment (such as music) interrupting the tone determines whether a tone 
resumes after completing an interrupting treatment. 


Tone transition before and after call event 

A ringback tone provided to a call because of a call presentation does not 
change the previous tone flag. For example, a controlled CCR call receives 
music before it is connected to an agent. This call receives a ringback tone 
before the agent answers it. However, if the agent presses the NRDY key to 
return the call to the queue, the call still receives the ringback tone. If the 
CCRM application now issues the Give RAN command to this call, after 
getting RAN, the call will receive music instead of the ringback tone. 


Table 4 shows how different call actions affect the tone given to the call 
before and after the action. 
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Table 4 
Tone transitions 
Action Tone before action Tone after action 
Queue to No tone Ringback 
Queue to Silence Silence 
Queue to Ringback Ringback 
Queue to Music Music 
Dequeue No tone Ringback 
Dequeue Silence Silence 
Dequeue Ringback Ringback 
Dequeue Music Music 
Give RAN No tone Silence 
Give RAN Silence Silence 
Give RAN Ringback Silence 
Give RAN Music Music 
Give tone (silence) No tone Silence 
Give tone (silence) Ringback Silence 
Give tone (silence) Music Silence 
Give tone (ringback) No tone Ringback 
Give tone (ringback) Silence Ringback 
Give tone (ringback) Music Ringback 
Give music No tone Music 
Give music Silence Music 
Give music Ringback Music 
Force disconnect No tone (call is gone) 
Force busy Whatever tone busy (call is gone) 
Route to Whatever tone (call is gone) 
Note 1: |f the Give Tone, Give Silence, or Give Ringback command is issued during the action, then the 
tone given to the call after the action is changed to the tone requested by the Give command. 
ete: The ringback tone is given to the call because a call presentation does not change the previous 
one flag. 
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Force Request 


Force Request changes the call state to the one indicated by the request. The 
supported options are disconnect and busy. This command removes the call 
from all queues where it resides and gives it the requested treatment. For the 
disconnect command, trunk calls are answered (if they are not already 
answered) and then disconnected. 


For the busy command, unanswered CO/FX/WATS trunk calls receive 
default treatment. Unanswered ISDN CO/FX/WATS trunks are allowed to 
receive busy tone. Other trunk types can be given busy tone if previously 
unanswered (no toll). 


When Forced Request is used, it must be the first command given in a script. 
If it is not, a caller will hear ringing before getting a busy tone or being 
disconnected. 


Route Request 


Route Request diverts the call to a specific DN as if the call had been dialed 
directly. The call is removed from the CDN and any other ACD queues, then 
routed to the specified target DN. 


The following DN types are supported: 


— Set DNs: any number that terminates on a user telephone 


— Trunk DNs: any number that accesses a trunk (such as trunk access 
codes) 


— Attendant DNs: any number that terminates to an attendant console 


— ESN DNs: any number (such as CDP, UDP numbers) that accesses the 
Enhanced Switching Network 


— ACD DNs and CDNs: all CDNs and ACD DNs in the customer’s system. 
However, the Route To DN cannot be the CDN that originated the call. 
If it is, an overflow tone is returned. 


Call abandoned 


When a call is abandoned while in the controlled mode of operation, the call 
is removed from all queues in which it resides, and an abandoned message is 
sent to the CCRM application. 
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Call presentation 

When a controlled call is presented to an ACD agent, the call is removed from 
all other ACD queues in which it has been placed. If the caller was receiving 
RAN or a tone, the caller now hears ringback. 


If the agent returns the call to the queue, it is returned to all ACD queues in 
which it was placed before the presentation. A call can be returned to queue 
only if there are no other idle agents for that queue. 


When a controlled CCR call is returned to the queue, it is placed at the head 
of priority 1 (timed overflow high-call queue) of the ACD queue. This assures 
that the next available agent receives the call. If this call was also placed in 
other ACD queues by queue commands from the CCRM application, it is 
replaced in each of its other ACD queues at the top of the priority at which 
the call was previously queued. With X11 Release 18 and later, the call is 
replaced in the queue in the same position it held before. 


The caller hears ringback when the call is placed back in its queue. 


Call answered 


When a call is answered during controlled mode, the X11 software notifies 
the CCRM application. The CCRM no longer controls the call. 


CCR call handling error detection 


Synchronization errors 


Four synchronization errors that affect the CDN can occur on a per-call basis. 
These are the four errors: 


— No scriptis available. Call receives default treatment. Ceiling value is 
checked. CDN is changed in protected memory to default mode, and a 
CCRO03 message is output on the maintenance TTY. 


— Anundefined CDN call. Call receives default treatment. Ceiling value is 
checked. CDN is changed in protected memory to default mode and a 
CCRO03 message is output on the maintenance TTY. 


— An invalid call ID is received. Call receives default treatment. Ceiling 
value is checked. 


— CCR cannot control the call. Call receives default treatment. Ceiling 
value is checked. 
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Switching from the controlled to the default mode of operation 


The X11 software reverts the calls controlled by the CCRM software to 
default mode under abnormal conditions such as the link going down. 
However, if the calls are initially in the default mode, abnormal conditions do 
not occur. 


During abnormal operation, calls already placed in one or more ACD queues 
remain in these queues until answered or abandoned. A call queued to one or 
more ACD DNs does not go to the default ACD DN, but stays in its queue 
and receives no further treatment (based on either the CDN parameters or the 
destination ACD DN parameters). When a CDN reverts to default, calls that 
are not queued to ACD DNs are sent to the default ACD DN (regardless of 
the ceiling level for the CDN) and receive EAR treatment. 


When a call in the controlled mode must be redirected back to Meridian 1 call 
processing, the following rules apply: 


— Ifacallis queued to an ACD DN because of the previous execution of a 
Queue Request, the call remains in the queues where it resides. 


— Ifthe call is not queued to any ACD DNs, the call is given the default 
treatment of the CDN in which it resides. Thus, it is queued at the default 
ACD DN of the CDN and thereafter governed by the rules regarding the 
default operation. 


— The call ceiling value is not checked when diverting these calls to the 
default ACD DN. However, they are included in the call ceiling count 
when a new call is diverted to default mode. 


The overflow threshold of the default ACD DN applies to the diverted CCR 
calls coming into the queue. 
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The call reverts to default under these circumstances: 


— Disabling of the AML in LD 48 or LD 96. X11 waits to receive a Start 
Up message from the CCRM application before returning to controlled 
mode. 


— Polling message timeout. X11 waits to receive a Start Up message from 
the CCRM application before returning to controlled mode. 


— Ten successive timeouts on CCR messages. A CCROO1 message prints 
on the maintenance TTY. X11 waits to receive a Restart or Start Up 
message from the CCRM application before returning to controlled 
mode. When the Restart message is received, a CCR002 prints out on the 
maintenance TTY. 


— Start Up received from the CCRM application. X11 waits for all calls in 
all CDN queues to revert to default mode as outlined above. 


— Shut Down received from the CCRM application. X11 waits for the 
CCRM application to send a Start Up message before returning to 
controlled mode. 


— CCR Died received from the CCRM application. X11 waits for the 
CCRM application to send a start message before returning to controlled 
mode. 


— CCR003 means a CDN was forced into default because there was no 
association in the CCRM. 


Trunk unit fault 


If a trunk providing RAN to a CCR-controlled call goes down, the CCRM 
application receives a treatment-complete message so that the call can 
continue its treatment as prescribed by the call script. 


553-2671-110 Standard 5.00 October 1997 


System features Page 107 of 278 


Operating parameters 


Prompts and responses 
The following prompts are added to LD 23 equipped with the CCR package: 


CNTL (Yes, No): is the CDN in controlled mode? 
VSID: VAS ID for Application Module Link for CCR. 
HSID: VAS ID for Application Module Link for host. 
CWTH: Call waiting LED threshold. 

BYTH: Busy queue threshold. 

OVTH: Overflow queue threshold. 

STIO: TTYs assigned for status displays. 

TSFT: Telephone Service Factor Threshold. 


CNTL prompt 

This prompt is given only if the system has the CCR package installed. The 
CNTL prompt determines whether the CDN is in controlled mode. When set 
to YES, the CDN operates in controlled operation. When set to NO, the CDN 
is restricted to using the default mode. 


CCR capacity impacts 
The following list describes the CCR impact on capacity: 


Real time—if 100 or more CDNs are defined, the ongoing status display 
could be affected. Therefore, a single script should be defined and used 
whenever possible for many DNIS numbers. For example, rather than 
defining a CDN for each DNIS number, define a single CDN and call 
script using IF statements within the script to provide different 
treatments based on DNIS numbers. 


Memory—each CDN takes up as much memory as an ACD DN. 
240 ACD DNs/CDNs can be defined per customer. 


Call registers needed for CCR should be added to existing NCR in 
LD 17. 


LD 17 — CSQI and CSQO should be increased by 25%. 
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— LD 17-CSQI + CSQO = 255 each. 


— Number of ACD trunks to CDNs minus the number of logged-in agents 
equals the number of unanswered calls times 7. 


Feature interactions 
ACD Ring Again 
This feature is not allowed to operate on CDN queues. However, once the call 


is queued at an ACD DN by default treatment or a route request, this feature 
is available if configured. 


Agent Display 

When a CCR call (either controlled or default) is either presented to or 
answered by the agent, depending on the agent’s display class of service, the 
agent’s display shows the following: 

— Originator Information 

— DNIS number (where applicable) 

— Original Called Information 

The Original Called Information category covers the CDN. The display of the 
CDN conforms to current X11 software operation. Therefore, if a call initially 
dials a CDN, the original called number (the CDN) is displayed when that call 


is presented to or answered by an agent, depending on the agent’s display 
class of service. 


The name of the CDN is displayed instead of the originator’s or DNIS name 
if the following conditions are met: 


— aname is defined for the CDN 


— the agent’s telephone has the Calling Party Name Display Allowed class 
of service 


— the DNAM option is not enabled in the incoming route block 


The redirecting number is the number of the last redirection. It changes as 
redirections occur within the network. 


553-2671-110 Standard 5.00 October 1997 


System features Page 109 of 278 


Under the best circumstances, the original called number and name are 
displayed on the terminating telephone. However, the redirecting number and 
name are used if a non-ISDN trunk or a switch that does not support the 
original called number message is encountered. A CDN can be a redirecting 
number and name. 


Agent/Supervisor keys 

If a CCR call is presented to an agent and the agent activates an 
Agent/Supervisor key, call handling occurs as described in “Not Ready key 
(Basic)” on page 36. 





Alternate Answering Service 
A CDN is not allowed to be an AAA DN. 


APL Messages 

If an AUX Processor is equipped, APL messages are sent across the APL link 
when an EAR or CCR call is given to an ACD agent through the default 
treatment or the Queue To command requested by CCR. 


Attendant Extension 


Attendant extension to a CDN is supported when the CDN is in controlled or 
default mode. 


An attendant initiating a call extension to a CDN in default is diverted to the 
default ACD DN. If the attendant completes the extension when the call is in 
the ACD queue, the call maintains its place in the queue. 


An attendant initiating a call extension to a CDN in controlled mode has an 
incoming message sent for it to the CCRM application module with the 
attendant as the originator. When the attendant completes the call extension 
by activating the release key, the call must be removed from all the ACD 
queues it is currently queued to and a call abandoned message must be sent to 
the CCRM application module. A new incoming message is sent for the 
extended call with the new originator information. The extension cannot be 
completed until the destination lamp on the attendant console is lit/wink. 
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Before the extension is complete, if the CCRM application sends Meridian 1 
a treatment request for RAN, the attendant is not allowed to receive RAN. An 
attendant is not allowed to receive Music treatment in both ACD and CCR 
operations. The CCRM application determines what treatments are given to 
calls. 


If the attendant extension is completed while the call is ringing on an agent’s 
telephone, a call abandoned message is not sent to the CCRM application 
because the call should be answered momentarily. If the agent activates 
NRDY instead of answering the call, the call is handled as described in “Not. 
Ready key (Basic)” on page 36. 





If the attendant extension is completed after the call is answered, no 
interaction occurs because once the call is answered the CCRM application 
no longer controls the call. 


Both ACD-C and ACD-D reports peg attendant extended calls as one call to 
the CDN. 


Aitendant Overflow Position 
A CDN is not allowed to be an attendant overflow DN. 


Attendant Recall 


Once a call is extended by the attendant to a CDN, it cannot recall back to the 
attendant console. 


Automatic Number Identification (In-band ANI) 


ANI information, if available, is provided to the CCRM application to use in 
call scripts. 


Auto-terminate trunks 


Auto-terminate trunks can terminate to a CDN (auto-termination number). If 
the trunk is designed as a DNIS trunk, the DNIS digits are delivered to the 
CDN and are carried with the call to ACD queues where it ends up by either 
default or controlled mode. 


Barge-In 
The attendant is prevented from barging into the originating trunk of a 
controlled or default CCR call. 
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Busy Verify 


The attendant is prevented from busy verifying the originating telephone of a 
controlled or default CCR call. 


Call Forward 

If the CCRM application issues a Route To command to a telephone that has 
call forwarded all calls, the call is forwarded to the appropriate destination. If 
the telephone has First Level Call Forward No Answer enabled, the CFNA 
DN for the Route To DN is obtained when the CFNA timeout occurs, instead 
of the CFNA DN for the dialed DN (the CDN in this case). The CCR call is 
forwarded to the next telephone. 


Calling Line ID (CLID) 


CLID information is provided for use in call scripts. It is also available for 
telephone displays and other applications to which the CDN can pass the call 
by route requests and default DNs. 


Call Party Name Display (CPND) 


The CDN can be assigned a name with the CPND feature. The CCRM 
application can also assign a name to the same DN by the variables feature. 
These two names are not coordinated and can be different. The name is also 
available for telephone displays and for other applications to which the CDN 
can pass the call by route requests and default DNs. 


Only M2317, M2008, M2x16, and M2616 telephones can have CPND class 
of service. Name information can be displayed only on these types of 
telephones. 


Call Park Recall 


If a controlled or default CCR call is answered by an agent who subsequently 
parks it, the call recalls back to the ACD DN of the agent and not the CDN. 


Call Transfer 


The CCRM application must be informed of the call transfer because the 
originating information (such as CLID and DNIS number of the transferring 
party) could differ from that of the transferred party. 
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Scripts created on the CCRM application can have conditional branching 
based on the originating information. Therefore, when a transfer is completed 
while the call is in the CDN queue, it is taken out of all the ACD queues to 
which it was queued. 


If the agent activates NRDY instead of answering the call, the call is placed 
to the front of the queue so it becomes the next in line to be answered. 


If the transfer is completed after the call is answered, no interaction occurs 
because once the call is answered, the CCRM application no longer handles 
the call. 


The transfer of a call to a controlled CDN cannot be completed until a valid 
tone or treatment request for the transferring party is received from the 
CCRM application, and successfully performed by the Meridian 1 (the tone 
can be ringback or silence, and the treatment can be Queue To, Route To, or 
give music or RAN). Both ACD-C and ACD-MAX (X11 Release 4) reports 
peg transferred calls as one call to the CDN. 


Additional Call Transfers are possible involving network call redirection. If 
Telephone A at Node A calls Telephone B at Node B, and Telephone B 
activates the transfer key initiating a transfer to a CDN at Node C, when 
Telephone B completes the transfer, Telephone A’s display is updated 
according to the mode of the CDN at Node C. If the CDN is in default mode, 
Telephone A gets the default ACD DN on the display if Telephone A is 
placed in the default ACD DN queue. Otherwise the display is updated with 
the number to which the default ACD DN diverts the call. 


If the CDN is in controlled mode, Telephone A gets the CDN on the display. 
The CCRM application is unaware of the transfer for this event since the 
Meridian | does not send the messages when the transfer is complete at 
Node B. 


Call Waiting Indication (AWC) 

If the New Call Waiting (NCWL) option is disabled, the number of calls 
queued to the ACD DN shown by the ACD calls waiting lamp (AWC) does 
not include controlled CCR calls. 


If the New Call Waiting option is enabled, the number of calls queued to the 
ACD DN shown by the ACD calls waiting lamp (AWC) includes CCR calls. 
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Once a default CCR call has been placed in the default ACD DN, it is 
considered a regular ACD call (except that the call gets its RAN and music 
treatment from its source CDN). Default CCR calls are reflected in the AWC 
display as regular (nonvirtual) CCR calls. Refer to the Night Mode section for 
a description of AWC when an ACD queue enters Transition or Night Mode. 


Centralized Attendant Service 


An attendant at the main site can extend a call to a CDN at a remote location. 
The extension cannot be completed until the destination lamp is lit/wink. 


CO trunks 


When a call enters the system by a CO trunk (including FEX and WATS), the 
Central Office provides ringback. This state is maintained until default or 
controlled treatment actions change it. Calls arriving on other trunk types 
receive silence until treatment for the call is decided (default treatment calls 
receive ringback or other tones as for calls directly dialed into the ACD DN, 
while treatments given to controlled mode calls are controlled by the CCRM 
application). Answer supervision must be returned on a CO trunk before the 
following treatments can be given: 


— music 

— silence 

— RAN 

— Force Disconnect 
— Force Busy 


Customer Night Number 
A CDN cannot be defined as a customer night number. 


Display Waiting Calls (DWC) key 

The light state of the Display Waiting Calls (DWC) key corresponds to the 
light state of the Calls Waiting (AWC) key. When the Display Waiting Calls 
(DWC) key is used at the supervisor’s or agent’s telephone, the display on the 
telephone is in the following format: 


aaa—bbb—ccc—dddd 
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Legend: 
aaa = number of calls in queue (TOF+high and nonpriority) 
bbb = number of agent positions occupied 
ccc = waiting time for the oldest call in queue 
dddd = virtual calls, which include source TOF, call request 


queue, and CCR-controlled calls 


Distinctive ringing 

Ringing is provided to calls originating from a route marked for distinctive 
ringing that has called or is diverted to a CDN in either controlled or default 
mode. 


DN Expansion 
Five- to seven-digit directory numbers are supported for CDNs. 


Dialed Number Identification Service (DNIS) 


This feature allows the software to store the last three or four dialed digits of 
a call arriving on DID or Tie trunks from the external network. This allows 
customers to identify the purpose of the call when a trunk terminates more 
than one number on the switch. 


The ACD DN to which the call is directed is obtained from the auto-terminate 
field in the protected trunk block, or it can be obtained through IDC 
translation tables. 


Calls arriving at an ACD DN by a CDN have the same DNIS information as 
if they had entered the ACD queue directly. 


Enable Interflow (ENI) key 
A CDN cannot have an ENI key defined for it. 


Enhanced Interflow 


Controlled CCR calls are not allowed to interflow. They are not included in 
the Overflow Threshold (OVTH) count. 
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Feature Group D (FGD) 

This feature provides ANI information (both calling and called party 
numbers) by FGD trunks. The calling party number (CLID) and the called 
party number (DNIS) are provided to the CCRM application for use in call 
scripts. 


Feature Invocation Messages 

This feature allows applications to invoke telephone features on behalf of 
individual telephones. Because this feature creates new ISDN/AP messages, 
changes to TFS008, Traffic Measurement, must be made to monitor these 
new messages. For more information, refer to Traffic measurement formats 


and output (553-2001-450). 


Hunting 

Only 500 and CDS, attendant, LDNs, or ACD DNs defined as message 
centers can be defined as an FDN or a Hunt DN. A CDN cannot be defined 
as an FDN or a Hunt DN. If a Route To command to a telephone is issued 
from the CCRM application, the call will hunt based on the parameters of that 
telephone. 


Incoming Digit Conversion (IDC) 


CDNs can be entered as a valid termination in the IDC tables. A call can be 
rerouted to a CDN based on entries in the IDC tables. 


Incremental Software Management (ISM) 


CDNs are counted as ACD DNs. For example, the limit specified by the ISM 
feature for ACD DNs applies to the sum of CDNs and real and virtual ACD 
DNs. 


Individual DN (IDN) keys 


An IDN key can be any DN key, such as SCR, MCR, SCN, and PLR. If an 
IDN key is activated while a CCR call is presented to the agent, call handling 
occurs as described in “Not Ready key (Basic)” on page 36. 





ISDN/AP Enhancements 


This feature enhances existing messages and adds new ISDN/AP messages as 
part of the ISDN/AP enhancement. 
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ISDN Signaling trunks (ISL) 

If an incoming call to a CDN in controlled mode is from an ISL trunk in 
which the D-channel is active, then the required ISDN signaling messages are 
sent to the far end when the first treatment request is received from the CCRM 
application. However, if the D-channel goes down, ISDN messages are not 
sent when the first treatment request is received from the CCRM application. 


Last Number Redial 


In the EAR feature, the stored number that can be redialed is the default ACD 
DN to which the call is routed by the default treatment instead of the normal 
dialed DN (which is the CDN in this case). 


Make Set Busy 


If a CCR call is presented to an agent and the agent activates the MSB queue, 
call handling occurs as it is described in “Not Ready key (Basic)” on page 36. 





Meridian Mail 


CCR controlled calls can be placed in a Meridian Mail queue by a Queue To 
command. The call is removed from all other queues where it resides when it 
is presented to a Meridian Mail port. 


For a route request, CCR relinquishes control of the call when the route 
request is issued and before it is answered. 


Multi-Tenant 

For controlled mode, tenant numbers are not checked when the CCRM 
application module requests Meridian 1 to queue a call to a particular ACD 
DN. If the originator of a controlled CCR call is queued to an ACD DN and 
has a tenant number that has denied access to that ACD DN’s agent’s tenant, 
the agent is unable to answer the call after connecting the CCR call to an 
agent. 


One guideline of the Multi-Tenant feature is that every ACD agent of an ACD 
DN have the same tenant number. It is recommended that the tenant to which 
the caller belongs have access to the tenants in which ACD DN queues reside. 
The ACD DN queues are the queues to which the call can be queued by the 
Queue To command or default treatment. The system checks the access by 
looking at the first agent in the agent list. If this agent’s tenant number is 
denied access to the originator of the call, the call receives intercept treatment 
and is denied access to this ACD DN. 
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For default mode, when a CCR call first enters the default ACD queue, it 
receives intercept treatment if the tenant number of the first agent of the 
default ACD DN is denied access to the originator of the call. 


No Multi-Tenant checking occurs when a call enters a CDN queue because a 
CDN does not have agents against which it can check tenant numbers. 


Network ACD (NACD) 

NACD target tables are not provided for CDNs, nor are CDNs allowed as 
targets for NACD Routing Tables of other ACD DNs. If a remote CDN is 
specified as a target in an ACD DN routing table, the remote node refuses the 
request and an error message is issued indicating an invalid DN. Controlled 
CCR calls can be sent to queue with NACD tables using the Route To 
command. 


CCR calls in default mode are allowed to access the NACD routing tables of 
the destination ACD queue where they reside, while controlled mode calls are 
not subject to NACD rerouting. 


The name of the CDN is sent to the target node if the CDN is the original 
dialed number. It appears as the original called number. 


Network Call Forward No Answer 

This allows a person to define a trunk access code or NARS/BARS for an 
FDN. When the call rings at the remote FDN, the originator’s display is 
updated with the redirection number (and name if defined). 


CDNs can be entered as remote FDNs since there is no cross-checking with 
the terminating node to verify the number entered. 


If a CDN in default mode is entered as a remote FDN, the originating 
telephone is updated with the default ACD DN if the call is put into the 
default ACD DN queue, or with the number where the default ACD DN 
diverts the call if the call does not remain in the default ACD DN queue. 
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If a CDN in controlled mode is entered as a remote FDN, the CDN number is 
updated on the originator’s display as soon as ringback is provided to the 
caller. (Ringback is provided to the caller when the CCRM application sends 
as a first command a Queue Request, a RAN request, or a Route To request. 
Ringback is also provided when a Give Ringback Tone request is received. 
Ringback is given regardless of whether the Give Ringback Tone was the first 
command received for the call.) 


Network Call Redirection 

This allows a person to define a trunk access code or NARS/BARS for a Hunt 
DN. When the call is ringing at the remote Hunt DN, the originator’s display 
is updated with the redirection number (and name if defined). 


Since the terminating node does not cross-check to verify the number entered, 
CDNs can be entered as remote Hunt DNs. 


If a CDN in default mode is entered as a remote Hunt DN, the originating 
telephone is updated with the default ACD DN if the call is put into the 
default ACD DN queue, or the number of wherever the default ACD DN 
diverts the call if the call does not remain in the default ACD DN queue. 


If a CDN in controlled mode is entered as a remote Hunt DN, the CDN 
number is updated on the originator’s display as soon as ringback is provided 
to the caller. (Ringback is provided to the caller when the CCRM application 
sends as a first command a Queue Request, a RAN request, or a Route To 
request. Ringback is also provided when a Give Ringback Tone request is 
received. Ringback is given regardless of whether the Give Ringback Tone 
was the first command received for the call.) 


This feature also provides terminating number display information for 
transfer and call pick-up redirections. For example, if Telephone A at Node 
A calls Telephone B at Node B, and Telephone B transfers Telephone A to a 
CDN at Node C, after completing the transfer, Telephone A’s display shows 
the following: 


— the CDN’s default ACD DN, if the call is put into the default ACD DN 
queue 


— the number where the default ACD DN diverts the call, if the call does 
not remain in the default ACD DN queue 


— the CDN (if the CDN is controlled) 
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Network CPND 


Network CPND includes a new prompt, RCAP, in the configuration per 
D-Channel to indicate whether to send the name 


— when the call is answered (ND 1) 


— when the call is presented (ND2) 


ND1 


If the ND1 option is enabled, the originator’s telephone is updated with the 
name at the time that the call is connected. Therefore, if a CDN in default 
mode is dialed, the originator’s telephone is updated with the name of the 
ACD DN of the agent who answered the call. However, if RAN is given 
before the call is answered, the originator’s display is updated with the name 
of the ACD DN whose queue the call is in. 


If a CDN in controlled mode is dialed, the originator’s telephone is updated 
with the name of the ACD DN of the agent answering the call. However, if 
RAN or music is given, the originator’s display is updated with the name of 
the CDN when the RAN or music is connected. 


ND2 


If the ND2 option is enabled, the originator’s telephone is updated with the 
name when the call is presented. Therefore, if a CDN in default mode is 
dialed, the originator’s display shows the name of the default ACD DN or the 
name of the ACD DN to which the default ACD DN diverted the call using 
NCFW, overflow by count, or interflow. 


If a CDN in controlled mode is dialed, the name of the CDN appears when 
the call is given ringback. Ringback is provided to the caller when the CCRM 
application sends as a first command a Queue Request, a RAN request, or a 
Route To request. Ringback is also provided when a Give Ringback Tone 
request is received. Ringback is given regardless of whether the Give 
Ringback Tone was the first command received for the call. 


If a Give RAN or Give Music command is issued before a Give Ringback or 
a Queue To command, the name of the CDN appears on the originator’s 
telephone at the time the call is connected to the RAN or music. When the call 
is answered, the name of the ACD DN of the agent answering the call is not 
updated on the originator’s telephone. 
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Network Call Trace 

A call within the ISDN network that is calling a CDN can have network call 
trace performed on it. The Network Call Trace (NCT) information collected 
for a default or controlled CCR call is discussed in different scenarios: 


— Telephone A dials a CDN in controlled mode. The NCT output shows 
ORIG node and TBD node information with STAT of DIAL. The rest of 
the output depends on what treatments the call receives. 


— Telephone A dials a CDN in default mode and the call is presented to an 
ACD agent immediately. The NCT output shows ORIG node and TERM 
node information with STAT of RING. 


— Telephone A dials a CDN in default mode and the call is waiting in the 
default ACD DN. The NCT output shows ORIG node and TBD node 
information with STAT of ACD. 


— Telephone A dials a CDN in controlled mode, CCR response timeout. 
The call is then routed to the default ACD DN and presented to an ACD 
agent immediately. The NCT output shows ORIG node and TBD node 
information with STAT of DIAL. 


— Telephone A dials a CDN in controlled mode, CCR response timeout. 
The call is then sent to the default ACD DN and queued. The NCT output 
shows ORIG node and TBD node information with STAT of DIAL. 


Network Call Transfer 

Network Call Transfer is supported for a CDN. If a caller on Switch A calls 
a telephone at Switch B and the telephone at Switch B initiates a transfer to a 
CDN at Switch A, when the transfer is completed the trunks between Switch 
A and Switch B are shut down. 


Night Call Forward 


Calls controlled by the CCRM application are not allowed to Night Call 
Forward. 


Night Key Digit Manipulation 

This feature allows an IDC route to have two routes defined—one for day and 
one for night. It also allows a new key (DRC) to toggle between the two 
routes on a per-route basis. 
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Since a CDN can be defined as a termination in an IDC table, then a call from 
an IDC trunk can terminate to a CDN through both the day and night tables. 


Night Service (NSVC) key 

CCR calls in controlled mode cannot be placed by the Queue Request in ACD 
queues that are in Night Service or Transition Mode. In addition, calls already 
residing in an ACD queue when the queue goes into Night Service (Night 
Mode) are removed from that queue. The CCRM application is not notified 
when calls are removed from a queue because of the ACD queue entering 
Night Service. 


When the default ACD DN of a CDN is in Night Service, all CCR calls 
entering the ACD queue by default treatment receive the Night Service 
treatment of the default ACD DN (Night RAN and Night Call Forward). 


CDNs are valid destination DNs for the Night Call Forward DN of an ACD 
DN. A Night Service (NSVC) key cannot be defined for a CDN. 


CCR calls do not queue to ACD DNs in Night Service. 


Transition Mode—NSVC key 

If a queue goes into transition mode by the Night Service key, calls already 
in the queue remain, but no new calls are allowed to enter the queue. An ACD 
queue remains in transition mode until all of the calls that were in queue when 
the transition mode was entered, including CCR calls that were placed in the 
queue by the Queue To command from the CCRM application, have been 
depleted. When no more calls remain to be answered, the queue enters Night 
Mode. 


If a queue that was in transition mode enters Night Mode before all calls that 
were eligible to be answered were answered (for example, the supervisor 
manually takes the queue from transition mode to Night Mode by the Night 
Service key), call processing proceeds as described in Night Service. 


Calls Waiting Indication (AWC) key 

If the New Call Waiting (NCWL) option is disabled for a queue, the number 
of CCR calls in that queue is not reflected by the AWC key lamps (the agents 
have no way of knowing if there are CCR calls in queue). 
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When a queue enters transition mode, agents do not have a true indication of 
the number of calls remaining to be answered since CCR calls are not 
included in the count when the NCWL option is not enabled. Therefore, the 
New Call Waiting option should be enabled for an ACD DN that will receive 
controlled CCR calls. 


If the New Call Waiting option is enabled for a queue, the number of calls that 
remain to be answered are reflected by the AWC key lamp when the queue 
enters transition mode. CCR calls are included when the New Call Waiting 
function is determining the number of calls remaining in queue. 


Display Waiting Calls (DWC) key 

When the ACD DN enters transition mode, the DWC display shows the 
following information: 

— aaa = number of calls waiting in queue 

— bbb = number of agent positions available 


— ccc = waiting time for the oldest call in the queue 


— dddd = the sum of CCR calls 


Night Mode by the NSVC key 
When an ACD queue enters Night Mode by the Night Service key, the CCR 
calls are treated the same as described in Night Service. 


Calls Waiting Indication (AWC) key 

When the ACD queue enters Night Mode, the AWC key lamp goes dark, 
indicating that no calls are eligible to be answered since the queue is in Night 
Service. 


Display Waiting Calls (DWC) key 

When the ACD queue enters Night Mode, all of the fields in the display are 
zero since calls are not eligible to be answered and the agents are unavailable; 
the queue is in Night Service. 


Night RAN 


A default CCR call receives the night RAN as it is defined for the ACD DN 
in which it is currently queued. 
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Night Call Forward 


Controlled calls are not allowed to Night Call Forward. Default CCR calls are 
allowed to Night Call Forward. 


Not Ready (NRDY) key 


If a CCR call in default mode is presented to an agent and the agent activates 
the NRDY key, call handling occurs according to current Meridian 1 software 
operation. 


If a CCR call in controlled mode is presented to an agent and the agent 
activates the NRDY key, the software presents the call to another idle agent. 


If there are no idle agents, the call is placed at the head of priority 1 (timed 
overflow high-call queue) of the ACD queue of the agent to whom the call 
was presented. This assures that the call is presented to the next available 
agent. If this CCR call was also placed in other ACD queues by queue 
commands from the CCRM application, it is replaced in each of its other 
ACD queues at the head of the priority at which it had been previously 
queued. The CCR caller hears ringback when replaced in the queue. 


When a CCR call is replaced in the queue, it is not relinked by time in the 
queue. This affects the DWC display, as well as the Oldest Call in Queue 
Statistics for CCR statistics. For example, if a CCR call is the only call in the 
queue, and it is presented then requeued because the agent presses the Not 
Ready key, the DWC display shows one call in the dddd field (the field that 
displays virtual calls), with a wait time of zero. The wait time is zero even if 
the caller has been in the queue longer than zero seconds. 


Observe 


If a CCR call is presented to a supervisor and the supervisor activates the 
Observe key, call handling occurs as described in “Not Ready key (Basic)” 


on page 36. 





Originator display 

The originator of a call receives a display update when the call is terminated 
or answered only if it is an internal call or within an ISDN network. When the 
originator places a call, the originator’s display shows the originally dialed 
number (a CDN if that was the originally dialed number). 
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Assuming the originator dials a CDN, when an agent answers the call the 
agent’s ACD DN appears. This ACD DN is either the default ACD DN of the 
CDN, the number that the default ACD DN diverted the call to (if the call 
received default treatment), or the ACD DN in which the call had been placed 
by a CCRM application command (if the call received controlled treatment). 


If the agent’s ACD DN has a name defined and the originator has CPND 
allowed Class of Service on the telephone, the name of the agent’s ACD DN 
appears after the agent’s ACD DN as follows: 


original dialed DN Agent's ACD DN Name of Agent's ACD DN 


Only M2317, M2008, M2x16, and M2216 telephones can have CPND class 
of service, and these are the only telephones that can display name 
information. 


Overflow by count 

When a call is placed in an ACD queue by default treatment for a CDN, the 
overflow threshold of that queue is followed. When the threshold is exceeded, 
any overflow destinations defined for the ACD DN are considered based on 
the existing rules for this feature. 


Controlled CCR calls that are queued by multi-queuing at an ACD queue do 
not count toward the ACD DN’s queue size when calculating whether the 
overflow (OVTH) and BUSY thresholds are exceeded. Also, controlled CCR 
calls placed in an ACD queue by the Queue To command are not subject to 
the overflow threshold. Even if the overflow threshold has been exceeded for 
an ACD queue, controlled CCR calls can still be placed in that queue and will 
not overflow. 


Therefore, a situation could occur where the combined number of ACD calls 
and controlled CCR calls exceed the overflow threshold. The CCRM 
application determines the number of CCR calls that are placed in an ACD 
queue. 


CDNs are not allowed as overflow destinations for Automatic Overflow. 


PDP 


CCR and PDP hardware are mutually exclusive. 
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Ringing Number Pickup 

A telephone within the same call pickup group as an ACD agent is not 
allowed to pick up a ringing ACD call. This also applies to CCR calls, both 
controlled and default. 


Set Agent Priority (SAPA) /Select Agent Position (SAGP) 
commands 


If the supervisor issues a SAPA or SAGP command against an agent while 
the agent is presented with a CCR call, call handling occurs as described in 
“Not Ready key (Basic)” on page 36 if the customer has installed ACD-C or 
ACD-D. 





Supervisor Control of Queue Size 

When calls are routed to an ACD DN or placed in an ACD queue because of 
default operation, the call can receive busy tone treatment due to this feature 
(provided this feature is configured at the destination ACD DN and the 
overflow conditions necessary to activate this feature are met). The decision 
to provide a busy tone depends on the origination party type (DID calls and 
CO calls). 


Supervisor Control of Queue Size interacts strongly with the CDN’s call 
ceiling function, since both use thresholds to control queue size. If the call 
ceiling threshold is less than or equal to the overflow threshold used by 
Supervisor Control of Queue Size, default CCR calls are not handled by the 
Supervisor Control of Queue Size feature because the call ceiling is always 
reached before the overflow threshold. When the call ceiling is reached, any 
new default CCR calls are not placed in the default ACD DN. They are 
handled by the call ceiling function. 


If the call ceiling for a CDN has not been reached, calls are allowed to go to 
the default ACD DN. When a default CCR call reaches the default ACD DN, 
it is subject to treatment defined for that ACD DN (except for RAN and 
music), including Supervisor Control of Queue Size. If a default CCR call 
reaches the ACD DN and the Supervisor Control of Queue Size is in force 
(for example, acting on incoming calls), the CCR call receives the treatment 
this feature applies to it. 
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For controlled calls, if the CCRM application requests the call to queue to a 
particular ACD DN that has the Supervisor Control of Queue Size feature 
activated, then the call is queued at the ACD DN regardless of its overflow 
conditions. These controlled CCR calls do not count toward the overflow 
condition of the ACD DN. 


Telset Messaging 

Telset Messaging allows a caller to leave a message with the Message Center 
while in an ACD queue without talking to an agent using telephone-based 
menus. This feature is supported for default CCR calls only. 


Timed Overflow and Enhanced Overflow 

When a call is placed in an ACD queue by the default mode of operation for 
a CDN, the call is allowed to time overflow by the time overflow timer 
(TOFT) value (or timer values for Enhanced Overflow) defined for the ACD 
queue. CCR calls placed in an ACD queue by controlled-mode treatment are 
not subject to timed overflow or enhanced overflow treatment. 


CDNs are not allowed as overflow destinations for enhanced overflow and 
timed overflow. 


Trunk Night Number 
A CDN can be defined as a Trunk Night Number. 


Trunk priority 

Calls arriving by incoming trunks can have two levels of priority: high and 
none. If a CCR call receives default treatment, it retains its trunk priority. 
However, if a CCR call receives controlled treatment, the priority of the call 
is controlled by the CCRM application, and one of four levels of priority, not 
associated with the trunk, can be assigned. In controlled mode, the trunk 
priority of a call is overridden by the CCRM application if it issues a queue 
request. A trunk priority on a default call cannot be overridden. 


Features requirements 


Customer Controlled Routing (CCR) is package 215. It requires Enhanced 
ACD Routing (EAR, package 214), Unique Call ID (CALLID), package 
247), and Command and Status Link (CSL, package 77). 


CCR reporting requires either Meridian Max 4.0 or ACD management 
reports (ACD-C, package 42). 
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Dialed Number Identification Service (DNIS) (Advanced) 


Several optional features make up the ACD Dialed Number Identification 
Service. After a general description of DNIS, each of these features is 
described in this section. 


DNIS overview 


The ACD Dialed Number Identification Service (DNIS) shows the last three 
or four digits of the dialed DN received from DID and Tie trunks on the ACD 
agent’s display. The total is limited to 27 characters including spaces. 


In telemarketing environments, Dialed Number Identification Services 
(DNIS) can reduce the time needed to serve a call. For example, the dialing 
plan can be configured so the DNIS digits can represent product lines or 
services. The ACD agent can then answer incoming calls with the correct 
response. 


DNIS offers these functions: 


displays the DNIS digits on an agent’s display 


displays information sent through the Application Module Link (AML) 
to the host computer on the agent’s display 


makes DNIS information available across all modifications to Customer 
Controlled Routing (CCR) 


beginning with X11 Release 19, makes DNIS information available 
across all modifications to 


Third Party Vendor Host Application (AML) 


Third Party Vendor applications via the Auxiliary Processor Link 
(APL) 


Network ACD (NACD) calls queued at a remote target 
Feature Group D (FGD) trunk calls 

Customer Controlled Routing (CCR) 

High Speed Link (ACD MAX and Meridian MAX) 
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With DNIS enabled, the agent’s display shows the following information: 
ACOD—MEM—DNIS 


Legend: 
ACOD = trunk group access code 
MEM = trunk member number 
DNIS = pulsed-in DNIS numbers 


DNIS Length Flexibility 


DNIS Length Flexibility modifies the number of digits currently supported (3 
or 4) to a range of 1-7. The Route Data Block defines the length of the DNIS 
information to display. This feature is supported by both ACD and NACD. 
The appropriate number of DNIS digits is preserved across call modification, 
included in Call Detail Recording (CDR) records, and sent across the 
Applications Module Link (AML). 


ACD DNIS routing (IDC-DNIS) and Name Display for DNIS also support 
this wider range of digits. 


DNIS operations 

When a call is received from a DID or Tie trunk, a verification is performed 
to make sure it belongs to a DNIS trunk group. If it does, the pulsed-in digits 
are collected and stored. When the proper number of digits are received, the 
call is auto-terminated at the ACD DN specified for that trunk. The pulsed-in 
DNIS digits are shown on the agent’s display. 


If an ACD DN is not specified for a trunk, a DNIS call defaults to the 
attendant, the DNIS number is not displayed, and an error message is printed 
at the maintenance terminal. The DNIS number is not displayed on the 
attendant console, but is displayed on the agent’s display when the call is 
extended. 


Host interface environment 

On call presentation, a message is sent across a link to the host computer, if 
equipped. This link could be the Meridian Link or the Auxiliary Processor 
Link, depending on the application. 
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Within host interface environments, DNIS messages are sent across the link 
for the following applications: 


— DNIS Call Presentation identifies the agent position for the host 
computer. 


— DNIS Call Answered informs the host computer that a DNIS call has 
been answered. A screen of information is be presented to a terminal at 
the agent position. 


— DNIS Call Disconnects informs the host computer that the agent who 
answered the DNIS call is available for other calls. 


Messages for the host interface contain the DNIS number and an agent ID 
number to identify the agent position for the host computer. The host 
computer needs a “look-up table” in the database to reference agent position 
numbers and the proper ports. The host computer can then send a screen of 
appropriate information to a terminal at the agent position when the call is 
answered. If the DNIS number is less than four digits, the number field is 
filled with leading zeros. These are all one-way messages from the switch to 
the host computer. 


The Auxiliary Processor Link consists of a hardware driver and a software 
driver used together to transmit messages and route commands between the 
host computer and the switch. The software driver sends message packets 
back and forth between the host computer and the switch. 


One end of the link terminates on the Serial Data Interface (SDI) port within 
the Meridian 1. The other end terminates on one of the Input/Output ports on 
the host computer. The physical link between the host computer and the 
switch is a full-duplex, asynchronous, 4800-baud data link, RS-232-C 
compatible. The Meridian Link requires the ESDI QPC-513 G card. 


Feature interactions 

With X11 Release 18 and later, DNIS Across Call Modifications preserves 
the DNIS information across certain call modifications and enhances DNIS 
operation and functionality. Refer to “DNIS Across Call Modifications 
(Advanced)” on page 137. Some of the following feature interactions may not 
apply with X11 Release 18 and later releases. 
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Call Transfer 


Before X11 Release 18, DNIS Across Call Modifications information was 
lost when calls transferred to another queue. Refer to DNIS Across Call 
Modifications in this document for additional information. 


Display 

Before X11 Release 18, DNIS only supported initial call presentation. Refer 
to “DNIS Across Call Modifications (Advanced)” on page 137 for additional 
information. The DNIS number was displayed for three events. 





— calls that Overflow to the queue 
— calls that Interflow to an internal destination 


— during Night Service when the NCFW destination is internal 


When a target agent answers a call that has overflowed, the source ACD DN 
is displayed with the DNIS number. 


The display is cleared when certain features interact with DNIS. After 
completing the functions listed here, the DNIS number is redisplayed after the 
dialing party is restored: 


— Call On Hold 

— Call Consultation 

— Calling Party Number key 
— Charge key 


For the features interacting with DNIS, the display clears during operation. 
DNIS is not displayed when the following functions are accessed: 


— Display Queue key 

— Observe Agent key 

— ACD Supervisor (ASP) 

— ACD Emergency (EMR) key 
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— Attendant Barge-In 

— Attendant Recall (ARC) key 
— Conference calling 

— Display (DSP) key 

— Parked Calls 


Digit Insertion 
DNIS routes are not eligible for digit insertion. 


Operating parameters 


Auto-terminating DID trunks, Tie trunks, and FGD-DNIS trunks (X11 
Release 19 and later) support DNIS. The DNIS number is not supported on 
any other trunk type. 


Auto-terminating ACD DNs for DNIS are specified at the trunk level. 


The DNIS call does not terminate until the proper number of digits are 
received. 


— Ifthe call terminates on a non-ACD DN, the DNIS number is not 
displayed and messages are not sent across the link. 


— The DNIS number display is not supported on the Electronic Switched 
Network (ESN) or for Trunk Digit Insertion (TDI). 


If ACD DN is not specified for auto-termination, the call defaults to the 
attendant. The DNIS number is not displayed on the attendant console. 


DNIS requires DNIS (package 98), ACD advanced features (package 41), 
and Digit Display (package 19). 


Refer to the feature package and dependency chart located in X// features 
and services. 
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The following are examples of database configuration performed on an 
Option 71 with X11 Release 18: 


LD 17 — Define SDI port for Auxiliary Processor Link. 


Response Description 


CHG Change existing data. 


CFN Configuration Record. 
NEW TTY 0-15 Add an APL port. 


aaaa Card type. 
aaaa = DCHI, SDI, SDI2, SDI4 


APL APL port connects to data link. 





LD 15- Define APL Link number and include DNIS for a customer. 


Response Description 
CHG Change existing data. 


CDB Customer Data Block. 
FTR Release 21 gate opener. 


XX Customer number. 
Dialed Number ID Service included. 


Auxiliary Processor Link number. 





LD 23 — Define ACD group. 


Response Description 
NEW Add ACD group. 
ACD ACD data block. 


XX Customer number. 


ACD Directory Number. 
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LD 10 — Define agent set for analog (500/2500 type) telephones. 


Response Description 


NEW Add a new agent. 
500 Analog (500/2500 type) set. 
AGTA ACD for 2500 type telephone allowed. 


ACD xxxx yyyy Xxxx = ACD DN 
yyyy = ACD Position ID 





LD 16 — Define a route with DNIS feature enabled. 


Response Description 

NEW Add a new route. 

RDB Route Data Block. 

XX Customer number. 
Route number. 
Auto-terminate trunk. 


ACD-DNIS route. 





LD 14 — Define a trunk that autoterminates on ACD-DNIS. 


Response Description 
NEW Add a trunk. 


DID Direct Inward Dialing trunk type. 


xy x = Route number defined in LD 16 
y = member number 


xxxx = ACD-DN defined in LD 23. 


Digitone signaling. 
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7 Digit DNIS for MAX 


The X11 Release 23 feature, 7 Digit DNIS for MAX (7DMAX), expands 
Automatic Call Distribution (ACD) Dialed Number Identification Service 
(DNIS) capabilities. With this feature, the Meridian 1 sends the complete 
seven digit DNIS number on all related messages to MAX. 


Previously, in all messages to MAX, the Meridian 1 reported the first or the 
last four digits of a greater than four digit DNIS. With the 7 Digit DNIS for 
MAX feature, however, when an ACD call arrives on a DNIS route, up to 
seven DNIS digits are received by the Meridian 1 and sent to MAX via High 
Speed Link (HSL). 


Operating parameters 


The 7 Digit DNIS for MAX feature functions when MAX Release 8 or later 
is configured or when the High Speed Link (HSL) protocol is 12 or above. 


The 7 Digit DNIS for MAX feature is not supported on an Auxiliary 
Processor Link (APL). 


The 7 Digit DNIS for MAX feature modifies the ACD-D messages which 
contain DNIS information. MAX Release 7 and HSL Protocol 11 or lower, 
however, are still supported and provide the previous functionality. 


As per the existing feature, if system initialization occurs during a call, DNIS 
information is not retained. 


As per the existing feature, if MAX is not functioning, the Meridian 1 is 
unable to send messages to MAX. 


Feature interactions 

Auto Terminating Trunks 

An Auto Terminating Route may be used as a DNIS route. In this case, when 
a call is received from an Auto Terminating trunk, the call terminates at the 
Automatic Call Distribution Directory Number (ACD-DN) that is defined for 
that trunk. The dialed DNIS digits are shown on the agent’s display. With the 
7 Digit DNIS for MAX feature, the affected MAX messages contain the 
seven digit DNIS number. 
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Call Detail Recording 


Call Detail Records contain all seven DNIS digits. 7 Digit DNIS for MAX 
does not make any changes to the CDR feature operation. 


Conference 
Transfer 


With the 7 Digit DNIS for MAX feature, affected messages for Conference 
and Transfer calls contain the seven digit DNIS number. 


Customer Controlled Routing 


Customer Controlled Routing (CCR) is not affected by the 7 Digit DNIS for 
MAX feature, as Application Module Link (AML) messages already contain 
the seven digit DNIS number. 


Feature Group D 


When a DNIS trunk call originates from a Feature Group D (FGD) trunk and 
the terminating agent performs call modifications, the DNIS number appears 
on the terminating set. If the DNIS-CDAR option of the incoming FGD 

trunk’s Route Data Block is enabled, the DNIS number is placed at the end of 
the CDR record. The DNIS modification supports one to seven DNIS digits. 


Multiple Queue Assignment 


There were no new MAX messages introduced with Multiple Queue 
Assignment (MQA). With the 7 Digit DNIS for MAX feature, affected 
messages contain the seven digit DNIS number. 


Network Automatic Call Distribution 


The Meridian 1 sends DNIS information to the target node which is used for 
the target agent’s set display or for ACD-D reporting. All seven DNIS digits 
are sent from the source node to the target node, regardless of the MAX 
release at the source node. 


Feature packaging 
The 7 Digit DNIS for MAX feature requires the following packages: 
— Dialed Number Identification Service (DNIS) package 98 


— Automatic Call Distribution Package D (ACDD) package 50 
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Feature implementation 


No change to the existing configuration procedure is required for this feature. 


Note: If MAX Release 8 or above is configured, the WDGT prompt in 
Overlay 16 will remain but will be used only for Auxiliary Processor 
Link (APL) messages. The WDGT prompt is no longer applicable to 
High Speed Link (HSL) messages. 


Feature operation 


No specific operating procedures are required to use this feature. 
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DNIS Across Call Modifications (Advanced) 


Available with X11 Release 18 and later, this feature enhances DNIS 
operation and functionality and preserves the DNIS name and number display 
across the following call modifications: 


Conference and No Hold Conference redisplays DNIS information 
when a call returns to a simple two-party call from a conference call. 


Transfer displays the DNIS information on the terminating telephone if 
an agent transfers a DNIS call. 


Privacy Release redisplays DNIS information when the third party 
releases. 


Mixed DNs redisplays DNIS information when a 500/2500 telephone 
disconnects. 


End-to-End Signaling redisplays DNIS information when a call is put 
on hold and then restored. 


Beginning with X11 Release 19, DNIS is also preserved after the following 
modifications: 


Parked Call redisplays DNIS information when a parked call is 
accessed or recalled. 


Network Automatic Call Distribution (NACD) allows the DNIS 
information from a source ACD DN to be used at the remote target 
agent’s set or terminal display. The DNIS information can be used to 
update the display or terminal screen, or in ACD-D reports. 


Feature Group D (FGD) supports using the DNIS number of an 
FGD-DNIS trunk for updating the agent’s set display or terminal screen, 
or in ACD-D reports. 


Third Party Vendor Applications (APL) support using the DNIS 
number for telemarketing applications. 


Third Party Vendor Host Applications (AML) support host 
applications that use the DNIS number to bring up the agent’s terminal 
screen. 
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— Customer Controlled Routing (CCR) can use the DNIS number to 
determine different call processing treatments for a DNIS trunk call. 


— High Speed Link (ACD-D Reporting) can use DNIS information to 
generate DNIS reports. 


Operating parameters 

If a system initialization occurs while doing a call modification, the DNIS 
number stored in the unprotected Trunk Data Block is cleared and is no longer 
available. 


DNIS Display Across Call Modification only supports two-party calls. 


DNIS Display Across Call Modification can only be preserved if the call 
modifications or redirections are performed within the same switch. For 
example, an agent receiving a call from a DNIS trunk at Site A transfers the 
call to Site B. The agent answering the call at Site B will not see the DNIS 
information. 


In NACD (X11 Release 19 and later), to display DNIS information on a 
remote target agent’s set does not require the DNIS package at the remote 
site. 


An NACD call that is rerouted to a remote target node will display either the 
DNIS name or the DNIS number, but not both (X11 Release 19 and later). 
The DNIS name appears if it is available; otherwise, the DNIS number 
appears. Availability of the name depends on enabling the IDC DNAM 
option and defining the DNIS name of an IDC-DNIS trunk call in the CPND 
table. 


DNIS Display Across Call Modification applies only to DNIS routes. 


Feature interactions 
ACD Emergency Key (EMR) key 


If the ACD Emergency Key is used during a DNIS call, the display is cleared 
during the operation. The DNIS number and name are displayed when the call 
is restored following completion of the operation. 


ACD Interflow Conditions 


For ACD Interflow conditions, the DNIS number and name appear on the 
Interflow DN Digit Display. 
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ACD Observe Agent key 


When the ACD supervisor uses the Observe Agent key in Silent Observe 
Mode, that is, OBTN = NO during a DNIS call, the display is not cleared 
during operation. In other Observe modes, the DNIS number and name are 
not displayed following completion of the operation. 


ACD Overflow 


For ACD Overflow, if the DNIS call overflows to the Target agent, the DNIS 
name is displayed after the Source DN. 


ACD Night Call Forward 


During night service, the DNIS number and name appear on the internal 
Night Service number. 


Call Consultation 


The DNIS number and name are redisplayed after the dialing party is restored 
for call consultation. 


Call Forward All Calls 


The DNIS number and name are displayed if the call has been forwarded to 
another station. 


Call Forward No Answer 


The DNIS number and name are displayed for Call Forward No Answer 
Calls. 


Call Park 


When a Parked DNIS call is recalled or retrieved, the DNIS number and name 
are redisplayed. 


Calling Party Number key/Charge key 


If the Calling Party Number key or Charge key is used, the DNIS number and 
name are restored when the operation is completed. 


Call Pickup 


The DNIS name and number are displayed for call pickup from another 
station. 
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Call Transfer 


For a transferred call, the DNIS number and name are redisplayed when the 
call transfer is completed. 


Calls on Hold 


The digit display is cleared. The DNIS number and name are redisplayed after 
the held party is removed from hold. 


CLID 

The calling number (CLID) is displayed if a call comes from the ISDN 
network. If a DNIS call comes from an ISDN network, the CLID name, if 
defined, and the DNIS number are appended after the CLID in that order on 
a telephone. With the development of Name Display for DNIS, the DNIS 
name replaces the CLID name. If a CLID call is redirected to a telephone due 
to ACD Overflow, Interflow, Night Call Forward, or non-ACD features such 
as Hunting or Call Forward No Answer, the source ACD DN or original party 
called is displayed after the CLID number. The DNIS name and number are 
appended after the redirected number. 


Conference/No-Hold Conference 

If the Conference key or No-Hold Conference key is used during a DNIS call, 
the display is cleared during the operation. When the call is restored back to 
the original two-party call, the display shows the DNIS number and name. 


End-to-End Signaling 
If an agent or internal telephone performs End-to-End Signaling, the DNIS 
information is redisplayed when the call is put on hold and then restored. 


Hunting 
The DNIS number and name are displayed for calls configured in a hunt 
group. 


Integrated Service Access (ISA) 

The basic IDC feature supports only incoming DID routes. With ISA 
enhancements in Release 17, the IDC feature was extended to support FEX, 
WATS, and Tie routes over an ISDN interface, and supports ISA and 
non-ISA service routes. If DNAM = YES and the name is specified, the name 
will be displayed on any alphanumeric digit display configured with Call 
Party Name Display Allowed (CNDA). 
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Meridian Mail 
The display remains only through Meridian Mail transferred calls. 


Mixed DNs 


When a 500/2500 telephone has the same DN appearance as a Business 
Communication Set (BCS), and the BCS is active on a DNIS call, the 
500/2500 telephone will be bridged into the call when it goes off-hook. The 
DNIS information is redisplayed when the 500/2500 telephone disconnects. 


Privacy Release 


If there is a multiple appearance DN, and the second DN appearance joins a 
conversation with a call from a DNIS trunk, the DNIS information is 
redisplayed when the third party releases. 


DNIS on CDR (Advanced) 


Available with X11 Release 18 and later, the DNIS number is appended to the 
end of the existing CDR record when the trunk disconnects. The DNIS 

number is put into the Start record for all cases. The DNIS number is put into 
the End record for all cases except when the incoming trunk disconnects first. 
The DNIS number is put into the Normal record when the call is established. 


Operating parameters 
The DNIS number is appended to the end of the CDR record following the 
Feature Group D digits, if the following apply: 


— the customer has the DNIS and CDR packages 
— the route is a DNIS route 


— the new DNIS option in LD 16 is ON 
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Name Display for DNIS (Advanced) 


Name Display for DNIS displays the DNIS number and name for IDC DNIS 
calls terminating on telephones equipped with a display. 


An option (DNAM) is provided at the route level for IDC routes to allow the 
display of the IDC name. This supersedes the display of the route name. 


All telephones with display and class of service Automatic Digit Display 
(ADD) and Called Party Name Display Allowed (CNDA) support Name 
Display for DNIS. 


These telephones include the following: 
— M2317 
— M3000 


— Meridian Modular Terminals (M2008, M2016S, M2616, M2216 
ACD-1, and M2216 ACD-2) 


— Attendant consoles (M1250 and M2250) 


Name Display for DNIS requires the following packages: 
— CPND (package 95) 
— _ DNIS (package 98) 


— IDC (package 113), which requires NFCR (package 49) and NCOS 
(package 32) 


Prompts in the CPND data block (LD 95) and in the Route data block (LD 16) 
allow a name to be defined for an IDC number belonging to a particular 
conversion table. For a description of all the prompts and responses, refer to 
the X11 input/output guide. 


Feature interactions 


With X11 Release 18 and later, DNIS Across Call Modifications preserves 
the DNIS information across certain call modifications and enhances DNIS 
operation and functionality. Refer to “DNIS Across Call Modifications 
(Advanced)” on page 137. Some of the following feature interactions may not 
apply with X11 Release 18 and later releases. 
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When the following functions are activated, the DNIS on the telephone 
display screen disappears and redisplays when the function is deactivated. 


— Call on Hold 

— Call Consultation 

— Calling Party Number key 
— Charge key 


The feature interactions for Name Display for DNIS are the same as those for 
the DNIS, except for the following differences. 


ACD Interflow 


For ACD Interflow conditions, the DNIS number and name appear on the 
display when the IFDN is internal. 


ACD Night Call Forward 
During night service conditions, the DNIS number and name are displayed. 


ACD Overflow 


If the DNIS call overflows to the target agent, the DNIS name is displayed 
with the source DN. 


Conference Calls 


If the Conference key is used during the DNIS call, the display is cleared 
during the conference operation. When the call is restored to the original 
two-party call, the new display does not show the DNIS number and name. 
Instead, the display shows the name associated with the route. 


Application Module Link (AML) 


DNIS Name Display provides the ACD DN, DNIS number, and position ID 
in the PCI message for the Meridian link. The DNIS name is not provided. 


Network ACD (NACD) 


DNIS Name Display is provided for ACD agents within the same switch and 
for network ACD. 
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ISDN Calling Line Identification (CLID) 


If a DNIS call comes from an ISDN network, the DNIS name replaces the 
CLID name. Additionally, the DNIS number and name are displayed on an 
attendant console after the CLID. 


Operating parameters 
Name Display for DNIS does not apply to auto-terminated DNIS calls. 


An IDC name can only be associated with an IDC number explicitly specified 
for IDC translation in LD 49. Partial conversions apply according to the 
following guidelines: 


— partial IDC conversion to a full DN, only one IDC name can be defined 
for the entire range of DNs represented by the partial IDC number (for 
example 33xx to 5006) 


— partial conversion to partial DN when the DN is a valid ACD DN 


For instance, if 33 to 5006 is specified, only one ID name can be associated 
with 33; 3300 to 3399 cannot be individually given a name unless explicitly 
specified as an IDC conversion. The IDC does not support the asterisk (*) or 
octothorp (#) as valid digits to translate. 


With DNIS Name enabled (DNAM = YES), the DNIS name overrides all 
other names, including the following: 


— Calling Party name or Redirected Party name 
— Route name 


— Calling Line Identification (CLID) name 
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Routing by DNIS number (Advanced) 


Routing by DNIS number enhances call distribution within an ACD system. 
This enhancement allows calls to be routed to a specific ACD DN, based on 
the DNIS number, instead of auto-terminating as described in the DNIS 
section. 


With Incoming Digit Conversion (IDC), as shown in Figure 6, a set of DID 
numbers can be matched to existing internal numbering plans. Incoming 
Digit Conversion (IDC) also allows the conversion of several different DID 
numbers to a single ACD DN. Complete or partial DNIS numbers can be 
defined in the IDC translation table using LD 49. Refer to the X// 
input/output guide for a complete list of prompts and responses. 


When the digits received are not in the IDC translation table but are valid for 
an ACD DN, the digits are passed without changes to the system. The IDC 
conversion is used only when needed. Invalid calls are routed to the attendant. 
Figure 6 shows how incoming DNIS numbers are handled by the Meridian 
system. 


Figure 6 
Incoming Digit Conversion 


Central Office (CO) Meridian 1 
DID Trunks ACD DN 1 


DNIS numbers Translation table 
4000 thru 4100 or DNIS numbers ACD DN 2 


ACD DN 3 


553-1303 





Feature interactions 


The feature interactions for routing by DNIS are the same as those for the 
DNIS, except for the following differences: 


Digit Insertion 
Digit insertion for DNIS routes is not allowed. 
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New Flexible Code Restrictions 

When enabling IDC in LD 15, you must respond Yes to both NFCR and 
IDCA. When not using New Flexible Code Restrictions (NFCR), respond No 
to the NFCR prompt. 


Outpulsing the asterisk and octothorp 


Calls with an asterisk (*) or octothorp (#) in the DNIS route are sent to the 
attendant. 


Operating parameters 

Feature assumptions and feature requirements for routing by DNIS are the 
same as those for the DNIS, except that in addition to the packaging 
requirements for DNIS, routing by DNIS requires Incoming Digit Conversion 
(IDC) (package 113). 
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Dual Value Added Server Identification 


The X11 Release 23 feature, Dual Value Added Server Identification 
(DVASID), allows two applications - Meridian Mail (MMail) and Meridian 
Link (MLink) - to monitor and control the Meridian Mail ports. Two different 
Application Module Links (AMLs) can be defined on a Meridian Mail 
Automatic Call Distribution Directory Number (ACD-DN), one link 
connected to Meridian Mail and the other to the Meridian Link module. 


As shown in Figure 7, MMail and MLink are connected, via the Application 
Module Link (AML), to the Multi Serial Data Link (MSDL)/Enhanced Serial 
Data Interface (ESDI) card on the Meridian | system. 


MMail and MLink connectivity to the Meridian 1 


MMAIL ACD-DN A 
VAS ID 1 Application Module Link (AML) # 4 mest 
P 


VAS ID 2 


553-7604 





To establish communication between the Meridian 1 and MMail/MLink, an 
association is established in Overlay 23 between the ACD-DN and the Value 
Added Server (VAS) ID of the corresponding AML. Please refer to LD 23 in 
the X11 input/output guide for information on how to configure the Dual VAS 
ID. 
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Previously, only one AML was associated with a single MMail ACD-DN. 
Therefore, AML messages were communicated only to MMail for any event 
on the MMail ports. With the Dual VAS ID feature, however, it is possible 
for AML messages to flow to both MMail and MLink. This allows MLink to 
monitor the activities of the MMail port. MMail can control the MMail ports, 
while MLink can only monitor the ports. 


For further information on Dual Value Added Server Identification, including 
feature interactions, please refer to Meridian Link documentation. 
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Enhanced ACD Routing (Advanced) 


Enhanced ACD Routing (EAR) provides the ability to differentiate the delay 
treatment given to ACD calls arriving from different sources, but queued to 
the same ACD DN. The number of calls that are forwarded from each source 
into the call-answering queue can be limited. EAR also provides flexibility in 
controlling various ACD treatments. 


A Control DN (CDN) is a special Directory Number not associated with any 
physical telephone or equipment, although it must fit into the numbering plan. 
It uses a count taken from the number of ACD DNs in a system included in 

the ACD DN limits of Incremental Software Management (ISM). A CDN is 
not configured with agents of its own, but specifies a destination ACD DN, 

known as the default, to which incoming calls are directed. 


Multiple CDNs can place calls into the same ACD queue, so different 
treatments can be given to these calls. The treatment given to the call is 
determined by the parameters of the CDN, not the ACD queue. 


RAN and Music treatments given to the call are defined for each CDN. Any 
other ACD treatment is applied as if the caller directly dialed the ACD DN. 
For example, if the default ACD DN is in Night Service, the call to the CDN 
receives Night treatment specified for the default ACD DN. 


Control DNs possess the following parameters in common with ACD DNs: 
— First RAN route and time 

— Second RAN route and time 

— First RAN on arrival control 

— Music route number 


— Report Control 
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In addition, each CDN also has the following distinctive attributes: 


— Default ACD DN. This is the ACD DN to which calls to this CDN are 
directed. It is similar to the NCFW DN except that it must be a local 
ACD DN. 


— A ceiling value that limits the number of unanswered calls that a CDN 
can have at its default ACD DN at any one time. New calls receive busy 
treatment once the ceiling is reached. CO trunk calls do not receive busy 
treatment; they are placed in the queue. 


New calls will receive a busy signal until the number of calls queued against 
the default ACD DN drops below the ceiling value. 


Calls arriving at a CDN are queued to the CDN’s default ACD DN. The 
default ACD DN (or queue) must be local. An ACD DN that is defined for 
data service access cannot be used as a default ACD DN. CDN calls retain 
their trunk priority when placed in the ACD queue. Calls placed in the ACD 
queue from a CDN are treated exactly like any other calls in the queue, except 
for those CDN parameters that differ from the queue’s parameters (for 
example, RAN and Music treatment). 


Call ceiling 


The call ceiling defines the maximum number of calls the CDN can place into 
its default ACD queue. Once the CDN reaches the call ceiling, any additional 
calls arriving at the CDN receive a busy tone until the number of unanswered 
calls from the CDN falls below the call ceiling. 


Once a call is answered by an agent in the default queue, it no longer counts 
against the CDN’s call ceiling. 


Because several CDNs can feed into the same ACD queue, the call ceiling can 
be used to control the flow of incoming calls from various sources into an 
ACD queue. By carefully configuring each CDN’s call ceiling, calls from an 
individual CDN do not overload the default ACD DN. This allows an 
equitable call answering pattern. Figure 8 shows a CDN call ceiling example. 
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CDN Call Ceiling example 


incoming calls 


CDN 4234 


call ceiling = 15 
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No fewer than 15 calls 
that arrive directly are 
allowed before overflow 


553-5026 
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Feature interactions 


ACD Ring Again 
Ring Again is not allowed to operate on CDN queues. However, once the call 
is queued at an ACD DN, Ring Again is available if configured. 


Agent display 

When an EAR call is either presented to, or answered by, the agent 
(depending on the agent’s display class of service), the agent’s display shows 
the following: 


— originator information 
— DNIS number (if applicable) 


— Original Called Information 


The CDN is covered by the Original Called Information category. The 
displaying of the CDN conforms to the current X11 software operation. 
Therefore, if a call initially dials a CDN, when that call is presented to or 
answered by an agent (depending on the agent’s display class of service), the 
original called number, the CDN, is displayed. 


If the CDN has a name defined for it, and if the agent’s telephone has the 
CPND allowed class of service, and the DNIS Name (DNAM) option is not 
enabled in the incoming route block, then the name of the CDN is displayed 
instead of the originator’s or DNIS name. 


Agent and Supervisor Keys 


If an EAR call is presented to an agent, and the agent activates an 
Agent/Supervisor key, call handing occurs as described in “Agent and 


supervisor communication (Advanced)” on page 24. 


Alternate Answering Service 
A CDN is not allowed to be an AAA DN. 


APL Messages 


If an AUX Processor is equipped, APL messages are sent across the APL link 
when an EAR call is given to an ACD agent through the default treatment. 
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Attendant Extension 
Attendant extension to a CDN is supported. 


Aitendant Overflow Position 
A CDN is not allowed to be an attendant Overflow DN. 


Attendant Recall 


Once a call is extended by the attendant to a CDN, it cannot recall back to the 
attendant console. 


Auto-terminate Trunks 


Auto-terminate Trunks are allowed to terminate to a CDN (auto-termination 
number). If the trunk is designated as a DNIS trunk, the DNIS digits are 
delivered to the CDN and are carried with the call to ACD queues where it 
ends with the EAR treatment. 


Busy Verify 


The attendant is not allowed to perform a Busy Verify into the originating 
trunk of an EAR call. 


Call Forward 


A CDN cannot be defined as an FDN. Further, if a user has a CFW key 
defined on the telephone and attempts to program the telephone to Call 
Forward All Calls toa CDN, this is not allowed and the overflow tone sounds. 


Call Park Recall 


If an EAR call is answered by an agent who subsequently parks it, the call 
recalls back to the ACD DN of the agent and not the CDN. 


Call Party Name Display (CPND) 


The CDN can be assigned a name with CPND as for any other DN. The name 
is also available for telephone displays and for other applications to which the 
CDN can pass the call. 


This feature operates only for M2317, M2008, M2216, and M2616 
telephones with CPND Class of Service. When a target agent answers a call, 
the agent position DN or Trunk Access Code is displayed. 
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Call Transfer 


Call transfer to a CDN is supported. Call transfer toa CDN automatically puts 
the call in the default ACD DN queue. If the transfer is completed when there 
are calls in the ACD queue, the call is removed from the ACD queue and 

linked into the back of the ACD queue with the new originator information. 


Additional Call Transfers are possible, involving network call redirection. If 
Telephone A at Node A calls Telephone B at Node B, and Telephone B 
activates the transfer key initiating a transfer to a CDN at Node C, when 
Telephone B completes the transfer, Telephone A’s display is updated 
according to the mode of the CDN at Node C. If the CDN has the EAR option, 
Telephone A gets the default ACD DN on the display if Telephone A is 
placed in the default ACD DN queue. Otherwise, the display is updated with 
the number to which the default ACD DN diverts the call. 


Calls Waiting Indication (AWC) 


Once an EAR call has been placed in the default ACD DN, it is considered a 
regular ACD DN call (except the call gets its RAN and music treatment from 
its source CDN). Therefore, an EAR call is reflected in the AWC display as 
a regular ACD call. 


Centralized Attendant Service 


An attendant at the main site can extend a call to a CDN at a remote location. 
The extension cannot be completed until the destination lamp is lit/wink. 


Customer Night Number 
A CDN cannot be defined as a customer night number. 


Dialed Number Identification Service (DNIS) 


The ACD DN the call goes to can be obtained from the auto-terminate field 
in the protected trunk block or can be obtained through IDC translation tables. 


Calls arriving at an ACD DN by a CDN have the same DNIS information as 
if they entered the ACD queue directly. 


Display Waiting Calls (DWC) 

Once an EAR call has been placed in the default ACD DN, it is considered a 
regular ACD call (except the call gets its RAN and music treatment from its 
source CDN). Therefore, EAR calls are counted for the DWC in the “aaa” 
field. 
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DN Expansion 
Five- to seven-digit directory numbers are supported for CDNs. 


Enable Interflow (ENI) key 
A CDN cannot have an ENI key defined for it. 


Hunt 
A CDN cannot be defined as an FDN or a Hunt DN. 


Incoming Digit Conversion (IDC) 
CDNs can be entered as a valid termination in the IDC tables. A call can be 
rerouted to a CDN based on entries in the IDC tables. 


Incremental Software Management (ISM) 
CDNs are counted as ACD DNs. For example, the limit specified by ISM for 
ACD DNs applies to the sum of CDNs and real ACD DNs. 


Individual DN (IDN) keys 

An IDN key can be any DN type key, such as SCR, MCR, SCN, and PLR. If 
an IDN key is activated while an EAR call is presented to the agent, call 
handling occurs normally. 


ACD Feature description 


Page 156 of 278 


System features 


Last Number Redial 


The stored number that can be redialed is the default ACD DN. The call is 
routed by the default treatment instead of the normal dialed DN, which is the 
CDN in this case. 


Make Set Busy 
If an EAR call is presented to an agent, and the agent activates the MSB key, 
call handling occurs as described in the MSB section. 


Multi-Tenant Services 

When an EAR call first enters the default ACD queue, it receives intercept 
treatment if the tenant number of the first agent of the default ACD DN is 
denied access to the originator of the call. 


Network ACD (NACD) 


NACD target tables are not provided for CDNs, nor are CDNs allowed as 
targets for NACD Routing Tables of other ACD DNs. If a remote CDN is 
specified as a target in an ACD DN routing table, the request is refused by the 
remote node and an NACD error message is issued locally indicating an 
invalid DN. 


EAR calls can access the NACD routing tables of the destination ACD queue 
where they reside. 


The name of the CDN is sent to the target node if the CDN is the originally 
dialed number. 


Network CPND 
Network CPND includes a new prompt, RCAP, in the configuration per 
D-Channel to indicate whether to send the name 


— when the call is answered (ND 1) 


— when the call is presented (ND2) 
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ND1 


If the ND1 option is enabled, the originator’s telephone is updated with the 
name at the time the call is connected. Therefore, if a CDN is dialed, the 
originator’s telephone is updated with the name of the ACD DN of the agent 
who answered the call. However, if RAN is given before the call is answered, 
the originator’s display is updated with the name of the ACD DN whose 
queue the call is in. 


ND2 

If the ND2 option is enabled, the originator’s telephone is updated with the 
name at the time the call is presented. Therefore, if a CDN is dialed, the 
originator’s display will show the name of the default ACD DN or the name 
of the ACD DN that the default ACD DN diverted the call to via NCFW, 
Automatic Overflow, or Interflow. 


Network Call Forward No Answer 

Enables a person to define a trunk access code or NARS/BARS for an FDN. 
When the call is ringing at the remote FDN, the originator’s display is 
updated with the redirection number (and name if defined). 


Since there is no cross-checking with the terminating node to verify the 
number entered, CDNs are allowed to be entered as remote FDNs. 


If a CDN is entered as a remote FDN, the originating telephone is updated 
with the default ACD DN if the call is put into the default ACD DN queue, or 
the number of wherever the default ACD DN diverts the call if the call does 
not remain in the default ACD DN queue. 


Network Call Redirection 

Enables a person to define a trunk access code or NARS/BARS for a Hunt 
DN. When the call is ringing at the remote Hunt DN, the originator’s display 
is updated with the redirection number (and name if defined). 


Since the terminating node does not cross-check to verify the number entered, 
CDNs can be entered as remote Hunt DNs. 


Ifa CDN is entered as a remote Hunt DN, the originating telephone is updated 
with the default ACD DN if the call is put into the default ACD DN queue, or 
the number of wherever the default ACD DN diverts the call if the call does 
not remain in the default ACD DN queue. 


ACD Feature description 


Page 158 of 278 System features 


This feature also provides terminating number display information for 
transfer and call pick-up redirections. For example, if Telephone A at Node 
A calls Telephone B at Node B, and Telephone B transfers Telephone A to a 
CDN at Node C, after completing the transfer, Telephone A’s display shows 
the following: 


— the CDN’s default ACD DN, if the call is put into the default ACD DN 
queue 


— the number of wherever the default ACD DN diverts the call, if the call 
does not remain in the default ACD DN queue 


The original called number (and name) is displayed on the terminating 
telephone; but if a non-ISDN trunk or a switch that does not support the 
original called number message is encountered, then the redirecting number 
and name is used instead. A CDN can be a redirecting number and name. 


Network Call Trace 

A call within the ISDN network that is calling a CDN is allowed to have 
Network Call Trace (NCT) performed on it. The Network Call Trace 
information collected for an EAR call is discussed in different scenarios: 


— Telephone A dials a CDN and the call is presented to an ACD agent 
immediately. The NCT output shows ORIG node and TERM node 
information with STAT of RING. 


— Telephone A dials a CDN and the call is waiting in the default ACD DN. 
The NCT output shows ORIG node and TBD node information with 
STAT of ACD. 


Network Call Transfer 


Network Call Transfer is supported for a CDN. If a caller on Node A calls a 
telephone at Node B and the telephone at Node B initiates a transfer toa CDN 
at Node A, when the transfer is completed, the trunks between Node A and B 
are disconnected. Handling of a call transferred to a CDN by Network Call 
Transfer is handled as described in “Call Transfer” on page 154. 
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Night Key Digit Manipulation 

This feature allows an IDC route to have two routes defined—one for day and 
one for night. It also allows a new key (DRC) to toggle between the two 
routes on a per route basis. 


Since a CDN can be defined as a termination in an IDC table, then a call from 
an IDC trunk can terminate to a CDN through both the day and night tables. 


Night Service Treatment 


When the default ACD DN of a CDN is in Night Service, all EAR calls 
entering the ACD queue receive the Night Service treatment of the default 
ACD DN (Night RAN, Night Call Forward). 


CDNs are valid destination DNs for the Night Call Forward DN of an ACD 
DN. A Night Service (NSVC) key cannot be defined for a CDN. 


Calls Waiting Indication (AWC) key 

When the ACD queue enters Night Mode, the AWC key lamp goes dark, 
indicating calls are not eligible to be answered since the queue is in Night 
Service. 


Display Waiting Calls (DWC) key 

When the ACD queue enters Night Mode, all of the fields in the display are 
zero. Since calls are not eligible to be answered and agents are not available, 
the queue is in Night Service. 


Night Call Forward 
EAR calls are allowed to Night Call Forward. 


Night Mode by the NSVC key 
When an ACD queue enters Night Mode by the Night Service key, the EAR 
calls are treated as described in the Night Service section. 


Night RAN 
An EAR call receives the night RAN as it is defined for the ACD DN in which 
it is currently queued. 
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Not Ready key 

An EAR call is presented to an agent and the agent activates the NRD key. 
There are no idle agents available; therefore, the call is placed at the head of 
priority 1 (Time Overflow high call queue) in the ACD queue of the agent to 
which the call was presented. This ensures that the call is presented to the next 
available agent. EAR calls hear ringback when replaced in the queue. 


Observe 

If an EAR call is presented to a supervisor, and the supervisor activated the 
Observe key, call handling occurs as it is described in “Agent Observe 
(Advanced)” on page 40. 





Originator display 

The originator of a call receives a display update when the call is terminated 
or answered only if it is a local call or within an ISDN network. When the 
originator places a call, the originator’s display shows the originally dialed 
number (a CDN if that was the originally dialed number). 


Assuming the originator dials a CDN, when an agent answers the call, the 
agent’s ACD DN appears. This ACD DN is the default ACD DN of the CDN 
or the number to which the default ACD DN diverted the call. 


If the agent’s ACD DN has a name defined, and the originator has CPND 
allowed class of service on the telephone, the name of the agent’s ACD DN 
appears after the agent’s ACD DN. 


Only M2317, M2008, M2x16, and M2216 telephones can have CPND class 
of service and these are the only telephones that can display name 
information. 


Automatic Overflow 


When a call is placed in an ACD queue by EAR treatment for a CDN, the 
Overflow Threshold of that queue is enforced. When the threshold is 
exceeded, any Overflow destinations defined for the ACD DN are considered 
based on the existing rules for this feature. 


CDNs are not allowed as Overflow destinations for Automatic Overflow. 
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Report Control 

A report can be turned on or off for a CDN. However, if the CDN has the 
report control option off, ACD-D messages are not sent for calls into the CDN 
and ACD-C statistics are not printed for the CDN. Therefore, it is 
recommended that the same reporting option be set for a CDN and all ACD 
DNs to which that CDN could have calls queued, so that the reports will be 
accurate. 


Ringing Number Pickup 
A telephone within the same call pickup group as an ACD agent is not 
allowed to pick up a ringing ACD call. This also applies to EAR calls. 


Set Agent Priority (SAPA) /Select Agent Position (SAGP) 
commands 


If, while an agent is presented with an EAR call, the supervisor issues aSAPA 
or SAGP command against the agent, call handling occurs normally. 


Supervisor Control of Queue Size 


When calls are placed in an ACD queue because of EAR operation, the call 
can receive busy tone treatment provided this feature is configured at the 
destination ACD DN and the Overflow conditions necessary to activate this 
feature are met. The decision to provide a busy tone depends on the 
origination party type, such as DID calls or CO calls. 


Supervisor Control of Queue Size interacts with CDN’s call ceiling function 
since both use thresholds to control queue size. If the call ceiling threshold is 
less than or equal to the Overflow Threshold used by Supervisor Control of 
Queue Size, EAR calls are not handled by Supervisor Control of Queue Size 
since the call ceiling is always reached before the Overflow Threshold. When 
the call ceiling is reached, any new EAR calls are not placed in the default 
ACD DN. Instead, they are handled by the call ceiling function, which could 
be busy if defined in the target ACD DN. 


If the call ceiling for a CDN has not been reached, calls are allowed to go to 
the default ACD DN. When an EAR call reaches the default ACD DN, it is 
subject to treatment defined for that ACD DN (except for RAN and music), 
including Supervisor Control of Queue Size. If an EAR call reaches the ACD 
DN and the Supervisor Control of Queue Size is in force (for example, acting 
on incoming calls), the EAR call receives whatever treatment this feature 
applies to it. 
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Telset Messaging 


Telset Messaging allows a caller to leave a message with the Message Center 
while in an ACD queue, without talking to an agent, using telephone-based 
menus. Telset Messaging is supported for EAR calls. 


Time Overflow and Enhanced Overflow 


When a call is placed in an ACD queue for a CDN, the call is allowed to Time 
Overflow by the Time Overflow Timer (TOFT) value (or timer values for 
Enhanced Overflow) defined for the ACD queue. CDNs are not allowed as 
Overflow destinations for Enhanced Overflow and Time Overflow. 


Trunk Night Number 
A CDN can be defined as a trunk night number. 


Trunk Priority 


Calls arriving by incoming trunks can have two levels of priority: high and 
none. If a call receives EAR treatment, it retains its trunk priority. 


Operating parameters 


Enhanced ACD Routing (EAR, package 214) requires ACD Basic features 
(ACD-A, package 45) and ACD Advanced features (ACD-B, package 41). 
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Enhanced Malicious Call Trace 


During an established call, the user of a telephone with MCTA class of 
service can invoke a call trace against the DID call. The feature can be 
configured so that a special signal (hook flash and optional DTMF digit 
string) is sent to the Central office. The malicious call can be recorded using 
a recording trunk. The call trace record can be printed on any SDI port with 
MCT defined as a user, as well as on maintenance TTYs and in the history 
file. 


The Malicious Call Trace (MCT) feature operates similarly to the ACD 
Emergency Key (EMR) feature when a recorder is on a conference call. The 
ACD telephone can activate both the malicious call trace and the EMR 
feature. 
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Enhanced Overflow (Advanced) 


Enhanced Overflow (EOVF) enhances Time Overflow (TOF) by increasing 
the number of ACD DNs targeted by an overloaded source ACD DN from 6 
to 100. With Enhanced Overflow (EOVF), any particular ACD DN 
configured as a target can accept calls from up to 100 other ACD DNs on the 
same switch. 


Diverting calls from the source ACD DN to the appropriate target ACD DN 
is controlled by Routing Tables configured in LD 23. Up to 20 different 
targets can be defined for each ACD DN. A timer, from 0 to 1800 seconds, 
can also be defined for each source ACD DN. 


Enhanced Overflow (EOVF) can define source and target queues for each 
ACD DN. EOVE sends incoming calls from an overloaded ACD DN to target 
ACD DNs (like Time Overflow) that are local to the source ACD DN. 


EOVF does not support routing calls between source and target ACD DN 
over network services. It is, however, a prerequisite for network routing. 


Routing tables 


Routing Table information is used to determine when and where calls are 
going from the source to target ACD DNs. There are two types of Routing 
Tables: Day Tables and Night Tables. The Day Table is used when the source 
ACD DN is in Day Service. The Night Table is used when the source ACD 
DN is in Night Service. 


Each Routing Table at the source holds up to 20 entries, each consisting of a 
target ACD DN, an associated timer, and status information for the target. 
Targets in each table are put in order by the system according to the target 
timer value, from the lowest value to the highest value. The timer associated 
with each target is used to decide when to issue a Call Request to that target. 
The table entries can be entered in any order, and the Table is automatically 
reordered when timer values are changed. If all the timer values are the same, 
the entries are listed in the order they are entered. 
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Day Table 

A Day Table is used when the queue is open and operating normally. The 
targets defined in the table are independent of the Automatic Overflow 
(OVDN) targets. It is possible to have the same target defined for OVDN and 
EOVF, if defined in both the routing table and at OVDN in LD 23. If no Day 
Table is defined, TOF operates as usual, if allowed. Basic TOF does not 
operate when a Day Table is defined. 


When the wait time exceeds the timer for the first target, the call is placed in 
the source TOF queue. The call can, at this time, be answered by agents in the 
source ACD DN or in Target 1. The system continues to track the wait time. 
When the timer for the second target expires, it is automatically included in 
the search. The call can now be answered by agents in the source ACD queue, 
the first target queue, or the second target queue. Targets continue to be added 
to the search as the timers expire. See Figure 9 for an example of the search 
patterns. 


Calls will not overflow through the Day or Night Table to a Target DN in 
Night Service. 
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Figure 9 
Day table routing 


Call enters the 
Source ACD DN 


Target 1 Day Table for the Target 5 
10 seconds Source ACD DN 120 seconds 


Target 2 


Target 4 
20 seconds 


Target 3 40 seconds 


32 seconds 
Call enters Source ACD DN. 
After 10 seconds, the call may be answered by Target 1 or the source queue. 
After 20 seconds, the call may be answered by Targets 1 or 2, or the source queue. 
After 32 seconds, the call may be answered by Targets 1, 2 or 3, or the source queue. 


So on up to 20 Target queues. 
553-5354 





Night Table 

A Night Table operates when the source queue is in Night Service. When the 
Night Table is defined, Night Call Forward DNs cannot be configured. There 
is no priority or TOF in Night Service. 


When a call is directed to the source ACD DN, the timer begins. The call rings 
until the first timer expires. After the timer expires, the calls can be answered 
by agents in Target 1. The system continues to track the wait time. When the 
timer for the second target expires, it is automatically included in the search. 
The call can now be answered by agents in the first target queue or the second 
target queue. Targets continue to be added to the search as the timers expire. 


A Night RAN can be provided to callers while they are waiting. 
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Hold in Queue for Interactive Voice Response (Advanced) 


Interactive Voice Response (IVR) units provide an automated method of 
providing and accepting information from a caller using computer-controlled 
voice playback to prompt for telephone touch-tone input. Hold in Queue for 
IVR enhances the existing CCR commands and options. After the IVR 
session, the IVR port transfers the call to the appropriate queue based on 
caller input to prompts. IVR capability can also be provided while a call is in 
an ACD queue. While receiving IVR treatment, the Hold in Queue for IVR 
feature enables the call to maintain its place in any ACD queue where it may 
reside. 


To access this feature, a caller must reach a CDN in controlled mode. AnIVR 
port can be a Meridian Mail agent, an IVMS agent, third-party vendor 
equipment appearing as a 500/2500 ACD agent telephone, or third-party 
vendor equipment appearing as an ACD SL-1 telephone. 


Feature interactions 


Not Ready 

If a CCR call is presented to an IVR port and that port enters the Not Ready 
state, an attempt is made to terminate the call on another idle IVR port. If no 
idle IVR ports are available, the call is placed at the head of the priority 1 
(time overflow high call queue) IVR queue. This ensures that the call is 
presented to the next available IVR port. 


If the call will receive Interruptible IVR treatment and is queued to ACD DNs 
when the call was presented to the IVR port, the call remains in those ACD 
queues. Therefore, when the call is reinserted in its [VR queue because of the 
IVR port entering the Not Ready state, the call is not requeued to its ACD 
queues, since it was never removed from those queues. 


If the call will receive Non-Interruptible IVR treatment, and the call is queued 
to ACD DNs when the call is presented to the IVR port, the call is removed 
from all of those queues. When the call is reinserted in its [VR queue because 
of the IVR port entering the Not Ready state, the call is replaced in all of its 
ACD queues in the same places it occupied before being removed for 
presentation to the IVR port. 
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If a CCR IVR call queued to an IVR queue or presented or connected to an 
IVR port is removed for presentation to a live agent, and the agent presses the 
Not Ready key, the CCR will not be replaced in the IVR queue. 


When a CCR call is requeued, the call receives ringback tone. 


When a CCR call is presented to an IVR port, the call remains in its CDN (the 
CDN’s queue length is not decremented). 


Make Set Busy 


If a CCR call is presented to an IVR port, and that port enters the Make Set 
Busy state, call handling occurs as described in “Not Ready” on page 167. 





SAPA/SAGP commands 


If a supervisor issues a SAPA or SAGP command against an IVR port while 
a CCR call is presented to it, the port enters the Not Ready state and the CCR 
call must be requeued. Requeuing the CCR call occurs as described in “Not 
Ready” on page 167. 





Only ACD-D customer agents enter the Not Ready state immediately 
following the issuing of a SAPA or SAGP command if the agent is idle or has 
a ringing call. If the agent is busy on a call, the agent will be placed in Not 
Ready when it disconnects from the active call. 


Supervisor Control of Queue Size 

If a Give IVR request is received from CCR and the IVR queue in which the 
call will be placed has the Supervisor Control of Queue Size feature activated, 
the call is queued at that IVR queue regardless of its overflow conditions. 
CCR calls do not count toward the overflow condition of the IVR queue. 
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Overflow by Count 

CCR calls queued to a given ACD/IVR queue through Queue To requests or 
Give IVR requests are considered virtual calls in those queues. Therefore, 
CCR calls queued to IVR queues do not count toward the IVR queue’s size 
when calculating if the Overflow (OVTH) and Busy (BUSY) thresholds are 
exceeded. Also, CCR calls placed in IVR queues using the Give IVR 
command are not subject to the Overflow threshold (that is, even if the 
Overflow threshold is exceeded for a certain IVR queue, CCR calls can still 
be placed in that queue and will not overflow). Therefore a situation could 
arise where the combined number of CCR and non-CCR calls exceed the 
Overflow threshold. The CCR application controls the number of CCR calls 
placed in an IVR queue. 


Network ACD (NACD) 


NACD is not supported. CCR calls placed in an IVR queue with the Give IVR 
request are not subject to NACD rerouting. 


Timed Overflow and Enhanced Overflow (TOF, EOVF) 


TOF and EOVF are not supported. CCR calls placed in an IVR queue with 
the Give IVR request cannot overflow. 


Enhanced Interflow 


Enhanced Interflow is not supported. CCR calls placed in an IVR queue with 
the Give IVR request cannot interflow. 


Calls Waiting Indication key (AWC key) 
AWC key for IVR queues 
AWC key for IVR queues is not supported. 


AWC key for ACD queues 

CCR calls in an ACD queue count as virtual calls. When the New Call 
Waiting option is enabled for an ACD queue, the number of CCR calls 
queued to the ACD DN shown by the ACD Calls Waiting Lamp (AWC) 
includes CCR calls. 


A CCR call to hear non-interruptible IVR is removed from its ACD queues 
when presented to an IVR port and is returned to those queues upon 
completing IVR. While out of its ACD queues, the call does not show as part 
of the count of calls in queue, assuming the New Call Waiting option is 
enabled for the queues. 
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Display Waiting Calls (DWC key) 

DWC key for IVR queues 

When the DWC key is pressed to display the number of calls waiting in an 
IVR queue, CCR calls in that queue are counted for the display as shown: 


aaa—bbb—ccc—dddd 


Legend: 
aaa = number of calls waiting in the queue (excludes CCR calls) 
bbb = number of agent positions available 
ccc = waiting time for the oldest call in the queue in seconds 
(includes CCR calls) 
dddd = virtual calls including source TOF, Call Request Queue, and 
CCR calls 


Calls queued to an IVR queue using the Give IVR request are considered 
virtual calls within the IVR queue and are counted in the ccc and dddd fields 
of the display. They also show up as part of the call count for the DWC lamp 
update if the New Call Waiting option is enabled for the IVR queue. 


DWC key for ACD queues 


A CCR call to hear non-interruptible IVR is removed from its ACD queues 
when presented to an IVR port and is returned to those queues upon 
completing IVR. While out of its ACD queues, the call does not show as part 
of the count of calls in queue in the dddd field of the DWC display, does not 
count as part of the oldest call in queue field (the ccc field), and does not show 
as part of the count of calls in queue for the DWC key lamp. 


Since CCR calls queued using the Give IVR request are not removed from 
their CDNs when presented to IVR ports, a DWC key for a CDN reflects the 
number of CCR calls for that CDN still unanswered by live agents. 


Non-interruptible CCR IVR calls are removed from queue when presented 
for two reasons. The first is to prevent call interruption if an agent becomes 
available to take the call. The second is to prevent confusion. For example, 
one CCR call is queued in an ACD DN. The call is connected to an IVR port 
to receive non-interruptible IVR treatment. If the call was not removed from 
queue, it appears to the agents and supervisors that a call is in queue and is 
ready to be answered. Since the CCR call is non-interruptible, agents are 
unable to answer the call. 
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Night Service 

CCR calls cannot be placed in ACD or IVR queues in Night or Transition 
Modes. Calls are removed from an IVR queue when it goes into Night Service 
(Night Mode). The CCR application is notified of each CCR call removed so 
that CCR continues executing the call script. Because the CCR calls in queue 
are removed, they do not receive Night Call Forward or Night RAN 
treatments. 


CCR calls presented to an IVR port or connected to IVR when an IVR queue 
enters Night Mode are not disconnected from their ports. 


Removal of a CCR call from its [VR queue because the queue enters Night 
Mode does not affect its placement in any other ACD queue where it might 
reside. 


When a call receives non-interruptible IVR, it is removed from any ACD 
queues where it resided upon presentation to an IVR port. If any ACD queue 
where the call has its place held enters Night Service during the IVR session, 
the call is not restored to that queue upon completing IVR. 


Transition Mode via the NSVC key 

If an IVR queue enters Transition Mode with the Night Service key, calls 
already in the queue remain, but no new calls can enter the queue. An IVR 
queue remains in Transition Mode until all of the calls that were in queue 
when Transition Mode was entered have been answered or abandoned, 
including CCR calls placed in the queue using the Give [VR command from 
the CCR application. When all calls are answered, the queue enters Night 
Mode. 


If a queue in Transition Mode enters Night Mode before all eligible calls are 
answered (that is, the supervisor manually takes the queue from Transition 
Mode using the Night Service key, or all agents log out), call processing 
proceeds as described in “Night Service” on page 171. 
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Ongoing Status Display 

When the IVR queue enters Transition Mode, the ongoing status display is 
the same as the current operation except for the new #VIRTUAL CALLS QD 
field. This field displays the number of CCR calls remaining to be answered 
(CCR calls are eligible to be answered when a queue is in Transition Mode). 
Calls in the Source TOF and Network queues are not shown in the new field 
because they are ineligible to be answered when the queue is in Transition 
Mode. 


Display Waiting Calls key (DWC) When the IVR queue enters Transition 
mode, the DWC display shows the following information: 


aaa—bbb—ccc—dddd 


Legend: 
aaa = number of calls waiting in the queue 
bbb = number of agent positions available 
ccc = waiting time for the oldest call in the queue 


dddd = the sum of CCR calls 


The aaa field displays the number of real calls waiting in the TOF, high, and 
non-priority queues. Since CCR calls are considered virtual calls, they are not 
included in the aaa field. However, since CCR calls are eligible to be 
answered when the ACD DN queue enters Transition Mode, they are 
reflected in the dddd field. Calls in the Source TOF and Network queues are 
not shown in the dddd field because they are ineligible to be answered when 
a queue is in Transition Mode. IVR calls are considered when determining the 
oldest call for the ccc field. 


Night Mode via the NSVC key 


When an IVR queue enters the Night Mode using the Night Service key, 
effects on CCR are as described in “Night Service” on page 171. 





Ongoing Status Display 

When the IVR queue enters Night Mode, the ongoing status display is the 
same as the current operation except for the new #VIRTUAL CALLS QD 
field. This field displays no calls because no calls are eligible for answering 
when the queue is in Night Mode. 
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Display Waiting Calls key (DWC) 
When the IVR queue enters Night Mode, all call-related fields in the display 


are zero since no calls are eligible for answering when a queue is in Night 
Mode. 


Originator Display 

A call’s originator receives a display update only when the call is terminated 
or answered if it is a local call or within an ISDN network. When the 
originator places a call, the originator’s display shows the originally dialed 
number (a CDN if that was the original dialed number). 


Note that only M2317, M2008, M2x16, and M2216 telephones can have 
CPND class of service. Only these telephones can display name information. 


Originator Display for Local Call 

Assume that as part of CCR treatment defined in a script for a CDN, when the 
call is answered by the IVR port, neither the IVR DN nor the IVR DN name 
(if defined) is shown. If the call is eventually answered by a live agent at an 
ACD DN, the agent’s ACD DN and the name of the agent’s ACD DN (if the 
name is defined and the originator has CPND allowed class of service) is 
shown on the originator display. 


Digital Set Screens 

Upon answer at an IVR port, digital telephone screens display as if the call 
were still ringing in the queue (that is, the screen displayed when the 
telephone is connected will not be shown). 


Originator Display for ISDN Call 

The display update for an ISDN call depends on the Remove Capabilities 
(RCAP) specified in LD 17 for the primary D-channel. Acronyms input in 
response to the RCAP prompts in LD 17 identify ISDN-specific capabilities 
supported by the far-end node. 


ACD Feature description 


Page 174 of 278 


Table 5 


System features 


Table 5 indicates the information shown on the originator display, depending 
on what is specified for RCAP and if the call is answered by an IVR port or 
an ACD agent first. Assume that an ISDN call has dialed a CDN and is 
queued to an IVR queue (using a Give IVR request) and to an ACD DN (using 
a Queue To request). The information displayed includes the indicated DN 
and name for the DN (if one has been defined and the originator has CPND 
allowed class of service). Assume the Give IVR request is the first command 
executed for the call (when Give IVR is the first request executed for a call, 
the call receives ringback until it is answered). 


Originator display for ISDN call 





IVR port answers first ACD agent answers first ACD agent answers 


after IVR given 





RCAP = ND1 


CDN information was 
given when IVR port 
answered. ACD DN 
information will not be 
given. 


CDN information given ACD information given 





RCAP = ND2 








As soon as ringback is 
given, CDN information 
is given. By the time the 
port answers, the 
display has already 
been updated. No 
additional information 
will be given. 





As soon as ringback is 
given, CDN information 
is given. By the time the 
agent answers, the 
display has already 
been updated. ACD DN 
information will not be 
given. 





As soon as ringback is 
given, CDN 
information is given. By 
the time the agent 
answers, the display 
has already been 
updated. ACD DN 
information will not be 
given. 





Call Transfer to CDN—Completed during IVR 





Assume that telephone A calls telephone B, telephone B initiates a transfer to 
a CDN, and part of the script treatment defined for the CDN involves a Give 
IVR request. If telephone B completes the transfer during the IVR session, the 
transferred call’s (telephone A) treatments must start from the beginning of 
the CCR script. 
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Conference to a CDN—Completing during IVR 


Assume that telephone A calls telephone B and telephone B initiates a 
conference to a CDN. Also assume that part of the script treatment defined 
for the CDN involves a Give IVR request. If telephone B attempts to 
complete the conference during the IVR session, the attempt is not allowed. 
A conference cannot be completed until a third party answers. For this 
feature, an IVR port is not considered a valid third party to which a 
conference can be completed. While telephone B is connected to an IVR port, 
it is considered in queue. Telephone B can only complete the conference 
when a live agent answers. 


Observe 
Observing an IVR port is not supported. 


500/2500 Line Disconnect 
The 500/2500 Line Disconnect feature is supported. 


AML Enhancements 
Through AML 500/2500 telephones, this feature supports the invocation of 
basic telephone features such as release, conference, and transfer. If the AML 
Enhancements feature is used to control 500/2500 IVR ports, the AML 
Enhancements feature interacts with Hold in Queue for IVR. If a release for 
a 500/2500 IVR port is invoked, it is treated as anormal release—the IVR 
session is considered complete. Conferenced and transferred calls are treated 
as if they were invoked manually. 

Feature packaging 
Hold in Queue for IVR is package 218 (IVR). It also requires the following: 
— ACD advanced features (ACD-B, package 45) 
— Enhanced ACD Routing (EAR, package 214) 
— Customer Controlled Routing (CCR, package 215) 


— Meridian Mail, Release 8 
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In-Band ANI (IANI) (Basic) 


In-Band ANI (IANI) allows a terminating ACD agent telephone to display 
the CLID number of a call coming in on a DID or Tie trunk. 


When a DID or Tie trunk originates a call, the system checks to see if it 
belongs to an In-Band ANI (IANI) trunk group. If it does, the system collects 
the ten ANI digits and displays them on an auto-terminating ACD agent’s 
digit display telephone. The number is not displayed until all ten digits are 
received. 


The desired auto-terminating ACD DN is specified at the trunk level (LD 14). 
The auto-terminating ACD DN can also serve as a standard ACD DN, but 
ANI numbers are not displayed unless the incoming call is on an IANI trunk. 


If an auto-terminating ACD DN is not available, the call will intercept to the 
attendant. The attendant can route the call to an ACD DN, and the ANI 
number is displayed on that ACD telephone display. The ANI number is 
displayed on both the attendant console and the terminating ACD DN agent’s 
digit display. 


The following section describes the interactions between ACD and IANI. For 
a complete description of the IANI feature, see X11 features and services. 


Feature interactions (IANI) 


ACD Answer/Call Supervisor/Emergency 


If the agent presses the Supervisor key (ASP) or the Emergency key (EMR), 
the digit display is cleared when the supervisor answers the call. The display 
remains clear while the supervisor is active with the call. If the supervisor 
releases the call first, the ANI number reappears on the agent’s telephone 
display. 


ACD Interflow (not basic) 


If an IANI call interflows to another predesignated local ACD DN, the ANI 
number is displayed on the overflow agent’s digit display. The source ACD 
DN is displayed following the ANI number. 


ACD Night Call Forward 


If an ANI call is forwarded to an ACD DN, the ANI number is displayed on 
the ACD agent telephone. 
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ACD Overflow by Count (not basic) 


If an IANI call overflows to another ACD DN, the ANI number is displayed 
on the overflow agent’s digit display. The source ACD DN is displayed 
following the ANI number. 


Activity code 


If the ACNT key is activated during an IANI call, the display is cleared. Once 
the activity code has been entered and the ACNT key pressed again, the ANI 
number reappears on the agent’s display. 


Attendant Recall 


If an ACD agent is active on an IANI call and activates the Attendant Recall 
key (ARC) to call the attendant, the agent’s display will show the attendant 
number when the attendant answers the call. The ANI number reappears 
when the attendant releases the call. 


Call Consultation 


If the agent is active on an IANI call and presses the TRN key for call 
consultation, the display is cleared. When the agent restores the IANI call, the 
ANI number reappears. 


Call Park 


If an agent parks an IANI call and it times out and recalls back to the agent, 
the ANI number is not displayed. 


Call Transfer 


If an agent transfers an IANI call to another ACD DN, the ANI number is 
displayed on the terminating telephone display. 


Conference 

If an agent activates the conference feature while active on an IANI call, the 
display is cleared. The display remains clear while the conference call is 
active. If the conferenced party releases first, the ANI number appears on the 
agent’s display. 


Display key (DSP) 

If the agent is active on an IANI call and presses the DSP key to display 
another key feature, the ANI number will not reappear when the DSP function 
is complete. 


ACD Feature description 


Page 178 of 278 


System features 


Hold 
Ifan ACD agent places an IANI call on hold, the ANI number reappears when 
the call is restored. 


NACD (not basic) 
If an IANI call diverts to a target node as a result of NACD, the ANI number 
appears at the target node. 


Time and Date 


If the agent presses the Time and Date (TAD) key while on an IANI call, the 
time and date will remain displayed throughout the call. To display the ANI 
number again, place the call on hold and retrieve it. The ANI number 
reappears. 


Time overflow (not basic) 


If an ACD agent receives an IANI call due to time overflow, the ANI number 
is displayed. The source ACD DN follows the ANI number on the display. 


Virtual agents 
Virtual agents are not supported for IANI calls. 
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Incoming Trunk restrictions (Basic) 


Abandoned ACD calls are removed from both incoming call queues and 
Recorded Announcements (RAN) unless the incoming trunk used for the call 
is a loop start trunk. Far-end disconnect on loop start trunks is only detected 
during ringing. If a call is routed to a Recorded Announcement (RAN), 
answer supervision is returned to the trunk and ringing is stopped. On RAN 
completion, the call remains in the queue on Silent Hold unless Music On 
Hold has been specified for the ACD DN. 


Note: Trunks without disconnect supervision should not be used for 
ACD systems. Incoming calls on trunks that do not provide for 
disconnect supervision are not released by the system when the agent 
ends a call. 
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INIT ACD Queue Call Restore 


The INIT ACD Queue Call Restore (ACDR) feature enables the Meridian 1 
to restore up to 1000 calls, either transient ACD calls in ACD queues or calls 
which are held by a controlled DN, when the system initializes. Calls not 
residing in ACD queues during system initialization are not recovered by this 
feature. 


During system initialization, each queued ACD call is scanned and classified 
as restorable or nonrestorable. Essential data associated with each restorable 
call is saved. Nonrestorable calls are skipped. This scan-and-copy routine 
continues until either the 1000 call limit is reached or all queued calls are 
scanned. When the 1000 call limit has been reached, a system message will 
appear. 


All restored calls are presented again as new incoming calls that originated 
during system initialization. The original start time of a restored call is not 
recoverable. Call history information is also not recoverable. For example, it 
cannot be determined that a restored call had been call parked or modified 
prior to initialization. 


ACD queue calls which received ringback, music, or a recorded 
announcement prior to system initialization receive silence during system 
initialization. Ringback or a recorded announcement is given again after the 
call is restored as a new call. Subsequent call treatment continues as expected. 


Operating parameters 


The INIT ACD Queue Call Restore (ACDR) feature is supported on the 
following Meridian 1 Systems: 11C, 51C, 61C, 81 and 81C. ACDR requires 
a minimum of 16K of unprotected memory. 


To be restorable, a queued ACD call must be trunk originated. However, for 
non-UIPE PRI trunks, only active calls are restored. Virtual ACD calls such 
as network queue calls are not restored by ACDR. Restorable calls which are 
aborted by the caller during a system initialization are forwarded to an ACD 
DN, where they can then be dropped by an agent. 


If the Application Module Link (AML) to Meridian Mail is not available 
during system initialization, restorable calls directed to the Meridian Mail 
ACD DN receive night treatment. Calls restored to a Controlled DN are 
redirected to the default ACD DN and receive that DN’s treatment. 
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Restorable calls originally in the Time Overflow (TOF) queue are reseated in 
either the High Priority (HI) queue or the Low Priority (LO) queue on the 
basis of trunk priority. Therefore, restored calls might not occupy the same 
priority queues that they did prior to system initialization. 


ACDR does not recover certain types of call information. For example, 
Automatic Number Identification (AND), Calling Line Identification (CLID), 
Feature Group D ANI, Dialed Number Identification Service (DNIS), 
Network Calling Party Name Display (NCPND) and redirection information 
is not recovered. 


Ringback after Call Restoration 


To provide ringback tone to a call, the Meridian | uses either Tone and Digit 
Switch (TDS) or Extended Conference TDS (XCT) cards. Calls restored on a 
Meridian | equipped with a TDS card receive ringback immediately 
following the completion of system initialization. Calls restored on a 
Meridian | equipped with an XCT card and without a TDS card receive 
silence until the XCT parameter download is completed. An XCT parameter 
download is triggered by system initialization. 


There is one exception to this rule. If a RAN is available before XCT is in 
service, RAN is given according to the customer’s configuration. If a RAN is 
not available and XCT is not in service, the caller receives silence. 


ACDR provides ringback tone to a restored call after XCT parameter 
download if all of the following conditions are met: 


— the call remains in the ACD queue 
— RAN/Music/Ringback is not in progress 


— RAN treatment has not been given after the call is restored 


Feature interactions 


ACD-C Management Reports 
No statistics are kept for reporting periods in which a system initialization has 
taken place. 


AML/CSL (ISDN/AP) 
Restored calls supply no DNIS, CLID, Network Call ID, or ANI information 
for inclusion in AML messages. 
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ACD Call Priority 


ACD priority calls lose their call priority when the system initializes. ACDR 
restores these calls as new calls. 


Automatic Number Identification (ANI) 


Restored calls do not retain ANI information, unless the call was an incoming 
call on an M911 trunk. 


Call Detail Recording (CDR) 


The CDR record does not include ANI, CLID, NCPND and DNIS 
information lost in the course of restoring a call. When a system initialization 
takes place, the start time for the CDR record is the time of call restoration. 
Consequently, the duration for an ACD queue call is calculated from the time 
of call restoration. 


Call ID 


All restored calls receive new call IDs. 


Call Park 
Parked calls are restored by ACDR as new incoming calls to the ACD DN. 


Call Redirection 

Calling Line ID (CLID) 

Dialed Number Identification Service (DNIS) 
Digit Display 

Feature Group D 

Network Attendant Services (NAS) 

Network Call ID 

Network Call Redirection 

Network Call Trace and Call ID Diagnostic 
Network Calling Party Name Display (NCPND) 


Call information associated with these features is lost after system 
initialization and call restoration. 
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Customer Controlled Routing (CCR) 

Nortel Symposium Call Center 

Calls restored to a Controlled DN are redirected to the default ACD DN and 
receive that DN’s treatment. Auxiliary processor (for example, CCR) links 
act as though they are unavailable during initialization. 


DASS/DPNSS/APNSS 

ACDR does not restore network information such as Originating Line 
Identities (OLI), Called Line Identification (CLI), Calling Line Category 
(CLC), and Trunk Identity (TID). 


Enhanced ACD Routing 


The call control of a restored CCR call shifts from the CCR application to the 
Meridian 1. When a CCR call reverts to default, it receives Enhanced ACD 
Routing treatment for the CDN in which it resides. 


Enhanced Network Routing 
Network ACD (NACD) 


A virtual call queued at a target switch is not restored if the target switch 
initializes. However, the associated actual queued call receives the treatment 
programmed for the source switch. 


Enhanced Overflow 


A call request queued at a target switch is not restored. The associated actual 
queued call at the source switch is restored as a new call. 


Hold in Queue for Interactive Voice Response (IVR) 


A Customer Controlled Routing (CCR) IVR call awaiting connection to an 
IVR at the time of system initialization is restored by ACDR. A restored call 
of this type reverts to the default ACD DN of the corresponding CDN. 


Integrated Service Access (ISA) Enhancement 
For each ISA call restored by ACDR, a counter is incremented to record the 
number of ISA calls on the service route. 


Meridian 911 Enhancements: Call Abandon 
ACDR restores M911 Abandoned calls waiting in either ACD or CDN 
queues. M911 ANI information is restored on the set display. 
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Meridian MAX 
For Meridian MAX, messages on restored calls are not balanced. 


Music on Delay 
Calls do not receive Music on Delay when system initialization takes place. 


Network Message Services 

When system initialization is completed and an AML link is not available, a 
restored call to a Meridian Mail ACD DN receives night treatment. If system 
initialization is completed and an AML link is available, a restored call to a 
Meridian Mail ACD DN does not receive night treatment. Indirect calls to 
Network Message Services are restored as direct calls. 


Primary Rate Access (PRA) 

PRA D channels are released during system initialization and reestablished 
after initialization is complete. Transient calls on the D channel will not be 
restored. Active calls (calls which are answered by a live agent or with RAN 
treatment) on a PRA D channel are restored. 


Trunk Anti-Tromboning 
Trunk anti-tromboning is not supported on a call restored by ACDR. 


Universal ISDN protocol engine (UIPE) 

ACDR introduces a new capability called call synchronization. Call 
synchronization is the reconciliation of active and transient call sets between 
the Meridian 1 and the Universal ISDN protocol engine (UIPE) loadware 
application. In the call synchronization process, the Meridian | sends INIT 
queue call restored information, in the form of “call rebuild” messages, to 
UIPE layer 3 loadware located on the Multi-purpose Serial Data 

Link / Multi-purpose ISDN Signalling Processor (MSDL/MISP) card. 


Prior to ACDR, the UIPE loadware application could only restore active 
calls. When call synchronization operations are complete, identical sets of 
active (answered by a live agent or with RAN treatment) and transient calls 
are retained by the Meridian 1 and UIPE application loadware. 


UIPE loadware sets a timer running when initialization starts. If UIPE 
loadware does not receive all of the call rebuild messages from the Meridian 1 
before the timer expires, the UIPE loadware restores only active calls. 
Transient calls are dropped. 


553-2671-110 Standard 5.00 October 1997 


System features Page 185 of 278 


Virtual Network Services (VNS) 
VNS calls which have not reached active state are not restorable. 


Feature packaging 


INIT ACD Queue Call Restore requires Basic Automatic Call Distribution 
(BACD) package 40. 


Feature implementation 


No administration changes are required to configure this feature. 


Feature operation 


No specific operating procedures are required to use this feature. 


ACD Feature description 


Page 186 of 278 


System features 


Multiple Queue Assignment (MQA) 


The Multiple Queue Assignment (MQA) feature enhances the capabilities of 
Automatic Call Distribution (ACD). This enhancement allows agents to 
service up to five ACD directory numbers simultaneously and permits agent 
roaming so agents have the flexibility to use any ACD agent position 
equipped with an eligible Meridian Set with Special Application Display. 


The agent’s Individual Directory Number (IDN) can be automatically 
forwarded to the agent regardless of what set they use to login. 


MQA allows Call Center customers to achieve a high level of control over the 
manner in which agents are assigned to calls. This capability gives Call 
Centre managers the opportunity to direct calls to agents whose skills match 
the needs of the caller or a specific queue. This functionality allows ACD 
agents to service one or more queues depending on their skills. Each queue is 
considered an agent skill thus making this feature a “skills based routing” 
product. 


This feature also allows ACD agents to assign a priority value to queues as 
well as a supervisor to whom they are to report. If the multiple queues have 
calls waiting, the agent will service the queue for which their assigned priority 
is the highest. If they are servicing multiple queues with the same assigned 
priority or are not using the Priority Agent feature, queues will be serviced on 
a round-robin basis. 


Operating parameters 


Multiple Queue Assignment is only supported on the Meridian 1 Options 
51C, 61C, 81 and 81C systems. This feature requires X11 Release 21 and 
Meridian MAX Release 7. 


It is highly recommended that configuration parameters (for example, 
Observe Tone, Call Forcing, Flexible Call Forcing Timer) are set similarly 
for all groups of ACD queues so that calls will be presented to agents in a 
uniform manner. 
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The MQA feature is only supported on the following Meridian 1 proprietary 
sets with displays: M2008, M2216 and M2616. These displays must contain 
the “special applications firmware” shipped standard with these sets since 
Release 15. The NT2K25xx and NT2K28xx are the displays containing this 
“special applications firmware.” These sets can be used in the MQA setting 
without displays; however, Multiple Queue Assignment does not apply. 


The MQA priority option in LD 23 must be provisioned and priority agent 
package 116 must be equipped if agents are to enter queue priorities at login. 


The Maximum Number of Agent Positions (MAXP) prompt in LD 23 defines 
the maximum number of agents that can login to an ACD group at any one 
time. MAXP must be set at a high enough value to account for the secondary 
agents that may be servicing that ACD group. 


The assignment of an agent to an ACD group is not removed when an agent 
logs out of a queue. It is removed only when the agent logs into a new queue. 


For agents to change queues that they are servicing, they must log out and log 
back in to a different set of queues. Supervisors can change the queues an 
agent is servicing, but they cannot add or delete queues. This is done through 
configuration control, and the agent does not have to log out for these changes 
to take effect. 


ACD C Reports are not supported and should not be configured for any 
customer when the MQA feature is equipped. 


Only the primary ACD DN defined on an agent set is saved during a Data 
Dump and thus preserved after a system reload (sysload). Any other ACD 
DNs and associated priority values will be lost if a sysload occurs. 


MQA provides an option for the automatic forwarding of agents’ IDN calls 
to any MQA-eligible agent position they may choose to use for login, but no 
Message Waiting Lamp will be provided for the agent at the set. 


For automatic forwarding of calls, if the Single Call Ringing (SCR), Single 
Call Non-Ringing (SCN), Multiple Call Ringing (MCR), or Multiple Call 
Non-Ringing (MCN) key is defined on a multiple appearance DN (MADN), 
calls forwarded to this DN will ring on all DN appearances as per normal 
MADN operation. 
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In order for agents to have automatic forwarding of their IDN calls, they must 
have an SCR, SCN, MCR, or MCN key defined on the set used to login. Calls 
will forward to the DN assigned to the lowest key number on the agent’s set. 
Without one of these keys, no automatic forwarding will take place. 


When MQA is enabled all agents using telsets eligible for MQA login are 
subject to the required change in MQA login process. 


Certain types of ACD DNs such as CDNs and Meridian Mail ACD-DNs 
cannot be specified at login by agents using MQA. If these types are specified 
at login, they will be rejected by the system. 


If attempts are made to disable the Report Option in an ACD data block while 
agents are logged in with the MQA package equipped, the operation will be 
blocked and the system will issue an error message at the Meridian 1 
maintenance console. 


“0” (zero) cannot be specified as an ACD DN by agents during login because 
it is reserved for deleting previous ACD-DNs, Priorities or Supervisors. 


Such keys as Speed Call and Autodial keys, are not supported for use as short 
cut methods during the login process. 


Unless modified prior to use with MQA, it is recommended that Predictive 
Dialing applications not be used with MQA agents. 


MQA agents cannot be reassigned to ACD DN’s with reports turned off via 
a Load Management Select Agent Position Assignment (SAPA) command. If 
an attempt is made to reassign an agent to an ACD DN with reports turned 
off, an error message will be printed and the reassignment will not occur. 


Feature interactions 


ACD Set Keys 
ACD Answer Agent 
ACD Supervisor Call 


The operation of these keys are independent of calls being taken and will 
operate similarly whether or not an agent is serving one or multiple queues. 
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Activity Code Key 

If ACD sets are configured with an Activity Code key, the agents can enter 
an activity code based on the ACD DN or CPND name that is displayed for 
each MQA call, identifying the queue that they are currently serving. 


Agent Key 

An ACD agent can reference a Supervisor via the Position ID in the agent’s 
Supervisor’s ID (SPID) field. A Supervisor can reference an agent via the 
Position ID on one of their AGT keys. However, they must reference each 
other. 

If the Supervisor Position ID assignment of an agent has changed at login, 
then the Supervisor Position ID specified will appear in the SPID field for that 
agent. If the agent’s previous Supervisor had an AGT key defined, the agent 
will no longer be associated with that key. 


Agent Waiting Calls Key 

The lamp associated with the Agent Waiting Calls (AWC) key does not 
change status based on call waiting in multiple queues. The lamp reflects the 
status of the queue being served, queue most recently served if an agent is idle 
or the Primary queue assigned to the set if an agent’s set is logged out. 


Emergency Key 

Answer Emergency Key 

When an agent presses their Emergency Key (EMR) they are immediately 
connected to the Supervisor and the call is terminated at the Supervisor’s set 
on the Answer Emergency Key (AMG). The Supervisor called will always be 
the one whose Supervisor Position ID is assigned to the ACD set. 


Call Hold Key 


If the hold call is used before an agent has completed the login process, then 
the incalls key darkens and the login attempted is aborted. 


Display Key 

If the Display Key is used to view information defined on the ACD DN key 
of an agent serving multiple queues, then the ACD DN displayed will be the 
current queue being served if the agent is active on a call. The last queue is 
served if the agent is not serving an ACD call or the Primary ACD DN if the 
agent is logged out. 
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Display Agent Key 
MQA does not impact the operation of this key since the queue agents are 
servicing is relevant to the information displayed on this key. 


Display Waiting Calls Key 

MQA changes the operation of this key. Instead of showing statistics for one 
particular queue, the information summarizes the data for all queues an agent 
may be logged into. For supervisors, the data for one queue associated with 
the key is still displayed since supervisors can have multiple Display Waiting 
Calls (DWC) Keys for multiple queues. 


Ring Agent Key 

The operation of MQA is independent of any calls being processed by an 
agent. If an agent is serving one or multiple queues it does not impact the 
operation of the Ring Agent Key. 


Not Ready Key 

When an agent is ready to service calls they deactivate the Not Ready Key. 
The next queue served may not necessarily be the same queue prior to 
activating the Not Ready Key. 


Supervisor Control of Night Service 

If an agent is serving multiple queues and the Supervisor puts a queue into 
Night Service, the agent will not receive calls from this queue unless the 
queue goes through Transition mode initially. 


Call Detail Recording 


The ACD DN used in CDR records for a given agent can change depending 
on which queue the an agent is servicing. 


Call Party Name Display 

When an ACD agent makes an outgoing call (for example, Conference, 
Transfer, and Secondary DN) the Calling Line Identification of the agent 
depends on the key “0” ACD DN definition. This will change depending on 
which queue the agent is serving or has served. The CLID can change for an 
agent as the queues they serve change. 
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Call Forcing 


Agents serving multiple queues are governed by the setting of the Call 
Forcing option depending on which queue is being served. 


If using Flexible Call Force Time (FCFT) option, the value of the FCFT from 
the previously served queue will be used. 


It is possible that an agent may be serving multiple queues with different Call 
Forcing definitions. It is recommended that these options be set similarly for 
all groups of ACD queues that individual agents may be serving 
simultaneously. 


Customer Controlled Routing 

The Customer Controlled Routing (CCR) receives statistics from the 
Meridian | system and uses this information to make decisions regarding the 
number of idle agents in a queue and the number of logged in agents in a 
queue. CCR users must realize that since agents can be available in multiple 
queues, the total number of available agents as viewed by CCR may not 
match the actual number. Thus, the CCR script intrinsics idle_agents and 
logged_agents must be interpreted differently depending on how many 
queues agents service. 


Meridian Link (AML) 


Application Module Link (AML) Set Feature Invocation messages can be 
used to login and logout ACD agents sets, but these messages do not support 
Multiple Queue Assignment login. The existing AML Set Feature messages 
can continue to be used in conjunction with MQA. These messages are only 
used to log an agent in to one queue, as originally implemented. 


If an AML message containing an ACD DN (for example, PCI, USM, SFN) 
is generated on behalf of an agent, the ACD DN will reflect the queue being 
served or the queue most recently serviced if no ACD call is active. 


Observe 


Agents serving multiple queues are governed by the Observe Tone (OBTN) 
setting for the queue they are currently serving. Thus, it is possible that an 

agent may be serving multiple queues with different OBTN definitions. For 
this reason, it is recommended that the Observe Tone option is set similarly 
for all groups of ACD queues that agents may be servicing simultaneously. 
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Night Service 

When agents in a particular queue logout, the queue goes into Night Service. 
With MQA activated, agents can service up to five queues. If an agent is 
serving multiple queues and logs out, any queues for which they are the last 
active agent go into Night Service. 


Network ACD 


MQA impacts the choice of agents to service calls. Network ACD calls are 
treated the same in the MQA environment as a single queue environment. If 
an attempt is made to route a call across the network to an ACD queue being 
served by agents assigned to multiple queues, then the call is presented to the 
first available agent in that queue. 


Feature packaging 


The Multiple Queue Assignment is package 297 and requires Meridian 
Modular Sets package 170 and Digital Sets package 88. 


If the option to permit ACD agents to enter Priorities at login is desired, 
Priority Agent Package 116 must be equipped. 


If automatic forwarding of agents’ non-ACD calls is desired, Phantom TN 
Package 254 must be equipped. 


Feature implementation 


Since MQA requires MAX, MQA parameters are configured in LD 23 under 
ADS data administration. 


Note: HSL must be disabled before changing MQA-related prompts. 


Only one Meridian MAX customer is allowed per system, and that customer 
must use the Agent ID login mode. 


LD 48 - Disable the High Speed Link. 





Command 


DIS SDI HIGH 
DIS HSL 


Description 


Disable the SDI port for high-speed link. 
Disable the high-speed link. 
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LD 23 - Enable Multiple Queue Assignment. 





Prompt 
REQ 
TYPE 
CUST 
AID 

- IDLB 
- IDUB 
- LOG 
MQA 


- MQAS 


- MQAP 


- MQCF 


- MCFD 


Response 
NEW CHG 
ADS 

XX 

YES 

(0001) - 9999 
IDLB - (9999) 
1-1000 

YES 


YES 


YES 


YES 


DDD 


Comment 

New or Change. 

Auxiliary Data System data block. 

Customer numbe.r 

Do the ACD agents on this customer operate in Agent ID mode 
Agent ID Lower Bound 

Agent ID Upper Bound 

Maximum # of agents that can be logged in at any one time 


MGA logins allowed for agents serving this customer 
MQA is only prompted if AID = YES and the MQA package 297 
is equipped. 


Agents allowed to enter Supervisor ID at login 


Agents allowed to enter Priority values at login 
Priority Agent package 116 must be equipped 


Allow Automatic Call Forwarding of Phantom TN to agent sets 
at login. Phantom TN package 254 must be equipped. 


0,1, 2 or 3 digit attached to Agent IDs. This associates Phantom 
TNs to specific ACD call agents. X= 0 digits. 





Note: The RPRT prompt must be enabled for all queues served by an agent to have MAX 
messages sent. 
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LD 23 — Set MAXP value. 


Response Comment 


CHG 
ACD 


ENL SDI HIGH 


ENL HSL 


Change existing data 

Automatic Call Distribution data block 
Customer number 

ACD Directory Number 


Maximum Number of Agent Positions 
Ensure that MAXP is assigned a high enough value to account 
for secondary agents. 





LD 48 - Enable the high-speed link. 


Description 


Enable SDI port for high-speed link 





Enable the high-speed link 


Feature operation 


Login Procedure 

The ACD agent login procedure using Agent ID mode without Multiple 
Queue Assignment requires the agent to press the Incalls key and enter their 
Agent ID digits. If these digits are valid, the agent is logged in and will service 
the ACD DN defined on the Incalls key. With Multiple Queue Assignment, 
an agent can serve up to five ACD queues simultaneously and has the 
opportunity to specify those queues at login time. 


Where previously an agent would specify their Agent ID, they must now 
specify their Agent ID as well as all ACD DNs they wish to service. 
Additionally, there are two options under the ADS administration prompts in 
Overlay 23 which, when enabled, allow agents to specify at login individual 
Priority levels for each ACD DN they are to service as well as the Supervisor 
ID of the Supervisor to whom they are to report. 
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There is an option available to have an agent’s IDN calls automatically 
forwarded to whatever MQA set they log in to. To have this functionality 
requires the Phantom TN package (option 254) to be equipped on the PBX, 
and the prompt MQCF must be enabled in Overlay 23. 


Login Without Priorities or Supervisor ID 

To login using the MQA feature, agents must enter their agent ID digits and 
all the ACD DNs (to a maximum of five) they want to service. Each field 
must be separated by an octothorpe or “#”. The entire digit string must be 
terminated with another octothorpe or “#’ to indicate to the system that all the 
desired ACD DNs have been entered. The following string of characters is an 
example of what the agent must enter for MQA login with no Priorities or 
Supervisor ID: 


Agent ID#ACD DN 1#ACD DN 2#ACD DN 3#ACD DN 4#ACD DN 5S## 


An Agent often services the same ACD queues time after time. In such cases, 
the ACD DNs (up to five) do not need to be re-entered. When no ACD DNs 
are specified during login, the ones assigned to the set from the previous login 
will be used. Enter the agent ID followed by a double # sign. If the agent ID 
is “1234”, the login would be “1234##”. 


Login in With Priorities and Supervisor IDs 

The standard login process is the same, however the agent must specify 
priority values and a supervisor ID along with the ACD DNs. A priority value 
can be specified for each ACD DN entered at login and the priority value to 
be associated with a particular ACD DN must appear immediately after that 
ACD DN, with the field separated by an octothorpe or “#”. Priorities can only 
be specified by agents at login if the MQAP prompt in LD 23 is enabled. 
Supervisors can only be specified by agents at login if the MQA prompt in 
LD 23 is enabled. 


The priority field for an ACD DN can be left blank by entering “##’ with no 
Priority value in the field. If the priority field is left blank, the Priority value 
from the set data block (the Priority value is entered at the PRI prompt in 
LD 11) will be substituted. 
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Entering a Supervisor ID at login is optional. The Supervisor ID field can be 
left blank by entering a “##”’ with no Supervisor in the field. If the field is left 
blank, the Supervisor ID defined on the set previously will be used. However, 
if the Supervisor ID field is left blank, you cannot enter 0 to remove the 
Supervisor ID value. Instead, you must login again and reenter the Supervisor 
ID. 


The following string of characters is an example of what the agent must enter 
for MQA login with Priorities and Supervisor ID: 


Agent ID#SUPV ID#ACD DN 1#PRI 1#ACD DN 2#PRI 2 
#ACD DN3#3PRI 3#ACD DN 4PRI 4#ACD DN 5#PRI S## 


The following string of characters is an example of what the supervisor must 
enter for MQA login with Priorities and Supervisor ID. Note that supervisors 
need not enter their supervisor ID: 


Agent ID#ACD DN 1#PRI 1#ACD DN 2#PRI 2 #ACD DN3#3PRI 
3#ACD DN 4PRI 4#ACD DN S#PRI S## 


If an invalid entry is made for the ACD DN, Supervisor ID or Priority, the 
agent is notified immediately on the display. The agent may then reenter the 
field. An valid entry which has been accepted can be removed by entering a 
0 followed by a “#’. The field can then be re-entered. The removed entry will 
be displayed proceeded by an “X”. The agent ID cannot be deleted during 
login. 
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Music Broadcast 


The Release 23 Music Broadcast feature expands existing Music 
functionality. 


The Music Broadcast feature allows the Meridian 1 system to broadcast 
music to several parties at one time via a single Music Broadcast trunk port. 
This feature supports Music on Hold (MOH). With Music Broadcast, Music 
is delivered via X11 software; hence, Conference hardware is not required. It 
is not necessary to share Conference resources with Conference features, 
such as Conference and Group Call. Music Broadcast supports both 
intra-group and inter-group music. Therefore, a Music trunk in each network 
group is not required. 


A Music Broadcast call consists of several one-way connections from the 
Music trunk to each caller. The Music Broadcast feature reduces the number 
of timeslots required for callers to listen to music while on call hold or call 
waiting in an Automatic Call Distribution (ACD) environment. One timeslot 
is required to enable Music trunk broadcasts. In addition, each party listening 
to music through the broadcasting music trunk requires one broadcast 
connection. The extra speech path resources that are needed for the existing 
Conference-based Music are unnecessary for Music Broadcast. 


The Music Broadcast feature also introduces the following enhancements: 
— Incremental Software Management limit 


— Traffic Study Option 


For further information on the Music Broadcast feature, please refer to X// 
features and services. 
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Music On Delay (Advanced) 


Music is heard by callers in an ACD queue who are not hearing the Recorded 
Announcement (RAN) or ringback tone, but are waiting in the queue for 
service. Music On Delay is triggered by the end of each RAN. The music 
continues until a subsequent RAN is provided, or the call is either answered 
or abandoned. 


ACD calls do not receive Music On Delay if RAN is not also specified. Music 
On Delay is provided after the first or second RAN, and between subsequent 
RANSs, until the call is answered or abandoned. 


The music for Music On Delay is obtained from a music source by a music 

trunk specified in Service Change and connected to a conference circuit card. 
Callers experiencing ACD delay are bridged into the conference circuit by a 
listen-only path. Each music trunk is assigned to a specific conference loop 

(not necessarily dedicated to music), and each ACD DN can be programmed 
for a different music source (if available). 
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Music On Hold (Basic) 


Music On Hold (MUS) is provided to trunks specified for music to 
terminating calls that have been placed on hold. 


The music is taken from a music source by a music trunk specified in Service 
Change and connected to a conference loop. Callers put on hold are bridged 
into the conference card by software through a listen-only path. Each music 
trunk is assigned to a specific conference loop, not necessarily dedicated to 
music. Each ACD DN can be programmed for a different music source. See 
the X11 input/output guide for Service Change information. 
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Night Call Forward (NCFW) (Basic) 


The Night Call Forward feature allows calls to be forwarded out of the ACD 
queue to another destination. The Night Call Forward (NCFW) feature holds 
the call while verifying that the destination is available. If the destination is 
busy, the call is returned to the ACD queue where it originated. The system 
attempts to connect the call to the NCFW number until the call is either 
answered or abandoned. 


If the source queue is in Night Mode and the Night DN is another ACD DN, 
the call can Night Call Forward. The call is forwarded if any of the following 
states exist for the Destination ACD DN: 


— It has agents available. 
— It is not in Interflow state. 


— Itis an available DN for NCFW. 
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The caller hears ringback when held at the queue awaiting a free trunk or DN. 
Table 6 defines the treatments for NCFW destinations that are available for 
incoming calls based on the call type. 


Table 6 
NCFW treatment by call type 





Call Type (Origin) 





Telephone Attendant CO Trunk DID/Tie Trunks 





Telephone | Busy Tone Re-Link to Re-Link to Re-Link unless eligible 
ACD queue ACD queue | for CCBQ, CBQCM, or 





























OHQ 
Attendant | Busy Tone Overflow Re-Link to Re-Link unless eligible 
Tone ACD queue | for CCBQ, CBQCM, or 
c OHQ 
2 
3 ACD DN Re-Link to Re-Link to Re-Link to Re-Link to ACD queue 
z ACD queue | ACD queue ACD queue 
® 
a Trk ACOD | Busy Tone Re-Link Re-Link Re-Link unless eligible 
= for CCBQ, CBQCM, or 
O OHQ 
z 
NARS Busy Tone Re-Link Re-Link Re-Link unless eligible 
for CCBQ, CBQCM, or 
OHQ 
Invalid DN | Overflow Overflow Overflow Overflow Tone is returned 
Tone Tone Tone 








Note: Calls cannot be re-linked to the ACD queue if the originator of the call is eligible for Coordinated Call 
Back Queuing (CCBQ), Call Back Queuing to Conventional Main (CBQCM), or Off-Hook Queue (OHQ) 
tones. Also, calls cannot be returned to the ACD queue if the originator is an internal station and the NCFW 
destination is outside the ACD environment. 
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Feature interactions (NCFW) 
ACD Ring Again 
Internal telephones with Ring Again applied against the ACD queue are not 
allowed to Night Call Forward (NCFW). However, if the NCFW destination 
is an ACD DN with ACD Ring Again defined, an internal telephone can 
activate ACD Ring Again against the call. 


Attendant Extended Calls 


The attendant cannot extend NCFW calls under invalid conditions. However, 
the attendant can extend NCFW calls after they have been returned to the 
ACD DN queue. The attendant as the originator decides if the call can be 
returned to the ACD DN queue or not. 


Call Transfer 


Call Transfers and Network Call Transfers cannot be completed when the 
NCFW treatment defined is a Busy or Overflow tone. Transfers can only be 
completed if the NCFW call has been returned to the ACD DN queue. 
Network Calls use trunk numbers (ACOD numbers defined) instead of DNs 
for call identification. 


CLID Route Selection 
Access codes for ANI trunks can be defined as valid NCFW destinations. 


Message Center 


When the NCFW destination defined is a Message Center telephone, the call 
receives an Overflow tone instead of messaging, and is not returned to the 
ACD DN queue. 


Network Ring Again (NRAG) 


Calls from trunks in the ISDN environment that are connected to a busy 
NCFW destination are returned to the ACD queue and are not allowed 
Network Ring Again. 


Overflow by Number 


Calls linked to an internal ACD DN through NCFW treatment are eligible to 
Overflow by Number to the target queue of the Interflow DN (IFDN). 


553-2671-110 Standard 5.00 October 1997 


System features Page 203 of 278 


Ring Again (RGA) 
Only internal telephones and trunks on the same trunk can activate RGA 
against an NCFW call. 


Trunk Group Busy 

If the NCFW number defined is a trunk access code, and the trunk has been 
busied out using the Trunk Group Busy key, the NCFW call is transferred to 
the attendant. 


Time Overflow 

If the source ACD DN is in Night Service, NCFW calls are not eligible for 
Time Overflow unless the call was in the TOF queue when the ACD DN was 
placed into Night Service. Then the NCFW feature is used to present calls 
from the TOF queue to the NCFW destination. No new NCFW calls are 
allowed to TOF. 


Feature requirements 


The call in NCFW is not returned to the source DN if the call originates from 
a trunk eligible for the following treatments: 


CCBQ = Coordinated Call Back Queuing 


CBQCM Call Back Queuing to Conventional Mains Off-Hook 
queue offer tone 
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Note 1: Loop start signaling trunks are not allowed to be diverted to the 
NCFW DN. If the Night Treatment defined is Recorded Announcement 
(RAN), there is no way to determine when the call is abandoned. 


Note 2: With ACD DISC SUP PK package, CO loop start trunks 
terminating to an ACD DN are allowed to NCFW or interflow. However, 
avoid the following situations: 


An ACD DN NCFW’s a local set that CFNA’s to MMail. 


b Night RAN is defined while NCFW = none. 


c Using an external route with SUPN = NO for either NCFW or 
interflow. 


In cases a and b, trunks become hung-up and must be manually disabled 
in LD 32. In case c, if the caller abandons the call, the destination set 
rings until the abandoned call is answered and the set goes on-hook 


NCFW can forward a call many times as long as the NCFW DNs are ACD 
DNs that are not in the Interflow state. If the NCFW DN is not an ACD DN, 
then the call is not allowed to return to an ACD DN through Hunting, Call 
Forward No Answer (CFNA), or Call Forward All Calls. 


Calls on trunks without answer supervision cannot Night Call Forward. 


When a Night Call Forward destination is busy, the caller may receive silence 
or unpredictable ringing until the destination is free. To alleviate this 
condition and to inform the caller of the status of the call, define a Night RAN 
route. 


Night Call Forwarding is not supported by the following features and 
services: 


— Direct Inward System Access (DISA) 
— Data Services 


— Call Park Recall 
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Night Treatment (Basic) 


This optional feature can be used to inform ACD callers that the ACD 
location is not in service for after-business-hours calls. These calls can be 
handled in three ways: 


— RANcan be provided as part of the Night Treatment for after-hours ACD 
calls indicating that the ACD location is closed. 


— Whether or not it receives RAN, the ACD call can be forwarded to 
another ACD location or to a Night Service number. Only internal calls 
or calls from trunks that provide disconnect supervision can be call 
forwarded for Night Treatment. 


— Notreatment at all can be given. Callers receive ringback tone until the 
call is abandoned. No answer supervision is given to the Central Office 
(CO) from the switch. 


The Night Treatment feature requires all agent positions to be equipped with 
a Make Set Busy (MSB) key. The feature is activated automatically when all 
agent positions assigned to an ACD DN operate the MSB key. On the 
500/2500 telephone, the MSB feature is activated when the agent performs a 
log out by entering the SPRE code plus 97. 
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Priority Agents (Advanced) 


Priority Agents allows ACD supervisors to assign priorities to agents on an 
individual or group basis. Calls to an ACD DN are presented to the highest 
priority agent. 


Priority Agents allows more experienced agents to receive more calls or 
allows a supervisor to assist during high-volume times. When an agent is not 
available, calls are placed in the Call Waiting queue. Calls are routed to the 
agent of the highest priority who has been idle the longest. Priority 1 is the 
highest priority. 


Priority Agents requires ACD-B to support the feature. Systems operating in 
an ACD-D environment need a minimum of X11 Release 9 to support the 
feature. 


Different machine types allow different capacities: 
— 32 priorities possible 
e MS,N, RT, S, ST, STE, and XN machines 
e System options 21, 21E 
— 48 priorities possible 
e NT and XT machines 
e System options 51, 61, 71, and 81 


An agent can have only one priority at a time. Virtual agents are not supported 
by priority assignments. When the agent logs in, the priority assigned to that 
agent is displayed on the telephone. 


The default priority is 1. Setting the priority at 1 gives all agents the same 
priority. Assigning agents to different priorities presents the first call to the 
agent of the highest priority who has been idle the longest. Priority 1 is the 
first priority level agent to receive calls. 


553-2671-110 Standard 5.00 October 1997 


System features Page 207 of 278 


Using the following features, calls are presented to the next available agent of 
the highest priority who is idle the longest. If there are no agents available, 
the call is queued to the high-priority or non-priority queue for that ACD DN. 


— Call Forwarding 

— Call Park/Recall 

— Conference calls 

— Interflow calls (FDN) 

— Night Call Forward DNs (NCFW) 
— Ring Again (RGA) 


— Transferred calls 


Priority Agent Groups 

A Priority Agent Group can include only one agent, or all the agents for a 
single ACD DN. Calls are routed to the highest priority group until all agents 
in that group are servicing a call. Subsequent calls will then be routed to the 
next priority level. 


Not Ready (NRD) Key 

If an agent presses the NRD key while a call is ringing, the call is routed to 
the next agent of the highest priority who has remained idle the longest. Calls 
are routed to the highest priority group until all the agents of that group are 
on a call. Calls are then routed to the next highest priority group, until all 
those agents are active on a call. If there are no agents available, the call is 
linked to the front of the queue from where it originated. 


If a target agent presses the NRD key when presented with a Time Overflow 
(TOF) call from its source queue, then the call is presented to the highest 
priority agent who has waited the longest. If there are no idle agents, the call 
is returned to the TOF queue for the source ACD DN. 


Time Overflow 

When incoming calls Time Overflow, the system searches for an idle agent 
in the source and target queues. The call is presented to the highest priority 
agent who has been idle the longest. When more than one target is defined, 
the system searches according to the order defined in LD 23. 
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Priority trunks (Basic) 


This optional feature allows the customer to designate certain incoming ACD 
trunks as having priority. When implemented through Service Change 
programs, calls to ACD DNs on priority trunks move directly to the front of 
any non-priority calls in the call queue. Any non-priority ACD calls in the 
queue maintain their position in relation to each other but are placed behind 
priority calls in the queue. Although ACD calls are not dropped or lost by the 
system, long waiting times for non-priority calls can be avoided by using 
Automatic Overflow. 
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Recorded Announcement (Basic) 
Recorded Announcements are specified for each ACD DN independently of 
the other ACD DNs. When the system determines that an ACD caller is ready 
to receive a recorded announcement (RAN), the caller is connected to a 
recording trunk at the beginning of the RAN cycle on a one-to-one basis. If 
an agent becomes available to serve a caller who is currently receiving a 
RAN, the RAN is interrupted and the call is presented to the agent. 


An attendant does not receive RAN treatment when extending a call. After an 
attendant completes the call extension to an ACD DN, the extended caller can 
receive first and second RAN or Music as defined for the ACD queue. The 
ACD RAN is not given to calls waiting in the attendant queue. 


Note: If an attendant originates a call to an ACD DN, it receives 
ringback only. 


A customer may want to give recorded announcements (RAN) and Music to 
all calls except those coming in on WATS trunks, yet have only one ACD DN 
for answering all calls. This can be done in two ways through the use of a 
“dummy” queue. 


— Overflow This method is useful when caller information is required. For 
example ISDN and CLID information is carried along with the 
overflowed call. 


Send the incoming WATS calls to the dummy queue. 


b To Overflow calls, a telephone must be logged in to the dummy 
queue. 


c Put the telephone in Not Ready. 
d Set the Overflow threshold to zero (0). 


e Assign the desired ACD DN as the OVDN and the calls overflow to 
the actual ACD queue. 


— Night Call Forward 
Send the incoming WATS calls to the dummy queue. 
b Put the dummy queue in Night mode. 


c Assign the desired ACD DN as the Night Call Forward DN, and the 
calls are forwarded to the Night Call Forward DN. 
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When the number of calls in a call queue exceeds the number of available 
agents, calls are delayed before being answered. RAN can be used to advise 
the caller of the delay. ACD allows a choice of two RANs per ACD DN, 
which operate independently of each other. Unlike the Music On Hold 
feature, RAN does not use the conference loops. 


First RAN (Before X11 Release 2) 


The system keeps track of how long each call receives a ringback tone before 
being answered and evaluates each incoming call on the basis of how long the 
most recently answered call had to wait. If the time expected to answer an 
incoming call exceeds a customer-defined time (t1), the call receives RAN at 
the beginning of the next RAN cycle. Delay Start must be defined in LD 16, 
the Route Data Block (RDB). 


A call that arrives in the queue when the Delay Threshold (t1) has not been 

exceeded receives the first RAN after the second customer-specified time of 
t2. After RAN, the call is placed on Silent Hold or else it receives Music On 
Delay, until answered or abandoned. A caller dialing the ACD DN hears an 
audible message describing a delay possibility and can disconnect, decreasing 
the holding time on the trunk under busy conditions. 


First RAN On Arrival 

If the response to FROA is NO in LD 23, all calls must wait for the duration 
of the first RAN timer (t1 as specified) before receiving the First RAN. If the 
response is YES, a call that is eligible for first RAN treatment receives it 
immediately after entering the ACD queue. 


Second RAN 


On completion of first RAN, a customer-specified timer for a Second RAN 
(t2) is started. Each call that has been in the queue longer than t2 seconds gets 
Second RAN. Second RAN is repeated every t2 seconds until the call is 
answered or abandoned. 


RAN summary 

In summary, first RAN is given either immediately upon being queued or at 
tl seconds later. Second RAN is presented t2 seconds following First RAN 
and repeated at t2-second intervals. The two RANs operate independently of 
each other. Both are optional and the customer can have just the first 
announcement or both consecutively. 
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The two timers, t1 and t2, have no fixed relationship to each other. This gives 
the customer the flexibility to specify the RAN treatment to suit the 
requirements of the installation. Factors such as the time allowed for the 
announcement and the waiting time between announcements depend on the 
type of recorded announcement equipment used. The system is compatible 
with Audichron, CODE-A-PHONE, Cook Electric, and Interalia 
announcement machines. Refer to QPC74 Recorded Announcement Trunk 
Card description (553-2201-194) for details on engineering and installation 
guidelines. 
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Recorded Announcement Broadcast 


The Release 23 Recorded Announcement Broadcast (RANBRD) feature 
expands the existing functionality of the Recorded Announcement (RAN) 
feature. Previously, the Recorded Announcement (RAN) feature used 
one-to-one connection between a calling party and a designated RAN trunk 
connected to a physical Recorded Announcement machine. Therefore, if four 
calling parties were receiving RAN treatment then four RAN trunks were 
occupied to provide this functionality. 


The Recorded Announcement Broadcast feature eliminates the need for 
multiple cross-connections to provide recorded announcement. With this 
feature, multiple calling parties receive RAN treatment from one RAN trunk. 
Thus allowing a RAN trunk to simultaneously broadcast announcements to 
maximum of 48 calling parties per RAN trunk. This expansion maximizes the 
usage of available RAN trunks. 


This feature also introduces the following enhancements: 
— Incremental Software Management limits 

— RAN signalling capabilities 

— Multi-Channel RAN Machine Types and Modes 


— Message Staging Through Queuing Thresholds for Delay Dial Start/Stop 
RAN machines 


— Music on Waiting 


— Traffic Study Option 


For further information on the RAN Broadcast feature, refer to X11 features 
and services. 
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Secondary DN Call Blocking (SDNB) (Advanced) 


Secondary DN Call Blocking (SDNB) blocks out new incoming calls to the 
Secondary DN on an agent’s telephone, so the agent can handle current ACD 
calls without interruption. An agent telephone is considered ACD active 
when a call is presented or connected to the agent’s ACD In-Calls key. 


With Secondary DN Call Blocking enabled (SDNB = Yes), an incoming call 
to the Secondary DN of an ACD active agent telephone receives a busy tone. 


When Hunting is allowed and the secondary DN is called, the incoming call 
hunts to the Hunt DN specified. 


When Hunting is denied and the secondary DN is called, the caller hears a 
busy tone. 


Calls cannot Camp-On or use Call Waiting but Ring Again is available. When 
the ACD In-Calls key is idle, incoming calls to the Secondary DN terminate 
normally. 


Multiple Appearance DNs 


Calls to Multiple Appearance Directory Numbers as secondary DNs are 

connected normally, unless the agent is active with an ACD call. If there is at 
least one telephone within the multiple appearance group not active, the call 
connects to that telephone. The appearances that are ACD active are ignored. 


Single Call Arrangements (SCR) 


When the incoming ACD call is answered, the Secondary DN lamp lights on 
all telephones with that DN. Another agent cannot enter this call unless the 
following occurs: 


— the first terminating telephone releases privacy, or 


— the new agent telephone has Privacy Override Class of Service 


While a call is active on a Multiple Appearance Secondary DN, no other calls 
can be originated from that DN from any other appearance. 
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Multiple Call Arrangements (MCR) 

When an incoming call is directed to the Secondary DN, the SDN rings on 
idle telephones only. If an agent is active on an ACD call and becomes idle 
while a call is ringing on the MCR SDN, the call is not presented to the newly 
idled telephone. 


While a call is active on a Multiple Appearance Secondary DN, other calls 
can be received on and originated on that DN from any other appearance. 


Set service options to block calls in LD 23. Refer to the X// input/output 
guide for a complete description of the service change programs. When the 
options are set as shown in Table 7, calls to the Secondary DN are either 
blocked or not blocked. 


Table 7 
Service options for SDNB 


SDNB Idle Ringing DCP PCP 


YES Not blocked Blocked Blocked Not blocked 
NO Not blocked Not blocked Not blocked Not blocked 





553-2671-110 Standard 5.00 October 1997 


System features Page 215 of 278 


Feature interactions 


ACD Not Ready 


When an agent is doing post-call processing (PCP) while using the Not Ready 
(NRD) key, incoming calls to the Secondary DN are not blocked by SDNB. 


Blocked Calls 
Calls using the following features are blocked by SDNB: 


Auto-Terminating Trunks 

e The call is never presented, but the caller hears ringback tone. 
Calls Transferred 

Conference calls 

Dial Intercom Group calls 

Group calls 

Hot Line and Hot Line List calls addressed to the Secondary DN 
Manual Trunk Terminations 

e The call is never presented, but the caller hears ringback tone. 
Overriding calls 

Private Lines 

e The call is never presented, but the caller hears ringback tone. 


Speed calls and System Speed calls 


Calls Not Blocked 


With SDNB enabled, the following calls to the Secondary DN are allowed to 
terminate normally: 


Calls Parked may Recall 


Manual signaling, or “buzzing” a Secondary DN 
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Calls Not Supported 


The following call services are not supported: 
— Calls Waiting 

— Camp-On calls 

— Telephone to telephone Call Waiting 
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Supervisor Control of Queue Size (Advanced) 


Supervisor Control of Queue Size allows ACD DNs to return a busy tone to 
selected call types. With this feature, an ACD DN can return a busy tone to 
new calls when all of the following conditions are met: 


— No Interflow DN is designated. 


— The number of calls in the queue meets or exceeds the Overflow 
Threshold. 


— No Overflow destinations are configured, or the Overflow destinations 
are busy, or the Overflow destinations are in Night Service. 


— The busy tone is configured for Supervisor Control of Queue Size 
(OVBU). 


— The call has not arrived on a two-wire or CO/WATS/FX type trunk. 


Supervisor Control of Queue Size allows busy tone treatment for calls from 
three possible origins: 


— internal calls (including transferred and conference calls) 
— _ attendant calls 


— DID or Tie trunks 


The treatment can be defined for each call type as busy tone or link in queue. 
The default for all call origins is link in queue. See LD 23 in the X// 
input/output guide to configure call treatment. 


Figure 10 provides a flowchart explaining how the supervisor can control 
calls. 
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Figure 10 
Flowchart for call treated with Supervisor Control of Queue Size 


New call arrives for Call placed in 
ACD DN queue 


Number of calls in 
queue OVTH ? 


Yes 
Call placed in OVDN 
queue Try overflow treatment 


No 


Yes 
OVDN queue BYTH? OVDN defined ? 


Try interflow treatment 


No 
Try busy tone treatment IFDN defined ? 


No 

Yes 
Call diverted to 
Interflow destination 


Call origin configured as link in queue 


Call origin ? 


Call origin configured as busy treatment 


Give busy tone treatment 553-2065 
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Table 8 illustrates this feature’s impact on ACD operations. 


Table 8 
Supervisor Control of Queue Size impact on ACD operations 
Number of Overflow 


calls meets Interflow destination 
or exceeds x er ACD 
DN defined Call origin : F 
the s functionality 
defined and 
Overflow 


Thresholds avala 
n/a unchanged 
n/a unchanged 
n/a unchanged 


internal busy tone or 
link in queue 


attendant busy tone or 
link in queue 


CO link in queue 
(WATS/FEX) 


DID or Tie busy tone or 
link in queue 
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Feature interactions 


CAS 


If a call is extended to an ACD DN by the Centralized Attendant Service 
(CAS), the call is treated like an attendant type call. 


Call Transfer 


When an ACD DN receives a call from a transfer, the call is considered 
internal. 


Conference 
When an ACD DN receives a conference call, the call is considered internal. 


Interflow 


If an Interflow DN is configured, this feature is inactive. Conversely, if an 
Interflow DN is not configured, this feature is activated. 


Night Service 

If a call is directed to an ACD DN then forwarded to another ACD DN by 
Night Call Forward (NCFW), the destination ACD DN treats it as a new call. 
The destination ACD DN programming determines the treatment. If Night 
Call Forward (NCFW) diverts a call to a DN that operates with Supervisor 
Control of Queue Size, a caller may hear the night RAN first, then receive a 
busy tone. It is recommended that a call not be forwarded to a Night DN with 
this feature enabled because it is possible that the RAN is heard before the 
busy tone. 
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Operating parameters 


Supervisor Control of Queue Size is configured on an ACD DN basis. This 
feature and Interflow treatment are mutually exclusive. 


Busy tone cannot be configured for CO trunk calls. Calls received from CO 
trunks are linked in queue. Central Office trunk calls Night Call Forwarded 
across Tie lines to an ACD DN can receive a busy tone under the following 
conditions: 


— ifthe call is answered at the local switch, then transferred to the remote 
one 


— ifthe call is presented to an ACD DN that is Night Call Forwarded to a 
non-ACD telephone and that telephone is Night Call Forwarded to the 
Night DN 
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Time Overflow (TOF) queuing (Advanced) 


Time Overflow (TOF) provides a way to give special handling to calls that 
have been waiting too long. Time Overflow (TOF) overflows unanswered 
calls to other queues based on a customer-defined time threshold. Once a call 
has Time Overflowed it can be answered by either the source ACD DN or 
target ACD DN agents. The source ACD DN queue and the target ACD DN 
queues are monitored to collect Time Overflowed calls and present them to 
the first available agent. 


The advantage of Time Overflow (TOF) is that it allows calls that have waited 
the longest to be answered first. Calls from the TOF queue can be answered 
by the first available agent of the source ACD DN or target ACD DN. 


TOF operation 


The high-priority and non-priority queues for each ACD DN are continuously 
monitored to find calls that exceed the Time Overflow Timer (TOFT) in 
LD 23. Calls that exceed the TOFT value are put in the TOF queue for the 
source ACD DN. 


There is one TOF queue for each ACD DN. Call priorities are maintained 
when a call is placed in the TOF queue. Priorities are maintained by inserting 
high-priority calls in the TOF queue before inserting non-priority calls. 


For each queue, there are three levels of priority: non-priority, high-priority, 
and TOF. 


Non-priority queues are for calls on trunks with ACD priority not required 
(CLS = APN in LD 14) and the Time Overflow Timer (TOFT in LD 23) has 
not expired. This also includes internal calls. 


High-priority queues contain calls on trunks with ACD priority required 
(CLS = APY in LD 14) and the TOFT has not expired. 


TOF queue contains calls with the TOFT expired. Calls in the TOF queue 
can be either APN or APY trunk calls, or both. 
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TOF operation by time 


1 
2 


A call enters the source ACD DN high-priority or non-priority queue. 


The calls remains in the source queue until the call waiting time meets 
the TOFT value. The call is placed in the source TOF queue. 


The call can be answered by any agent in the source ACD DN or by a 
target agent. 


TOF operation with Automatic Overflow 


1 


A call attempts to enter a source ACD DN high-priority or non-priority 
queue. The OVTH for the source ACD DN has been met or exceeded, but 
the BYTH for the target ACD DN has not been met. 


The call overflows by number to the target queue. It remains there until 
answered, abandoned, or the TOFT from the source expires. 


When the timer expires, the call is recalled to the source TOF queue. 


The call can be answered by any agent in the source ACD DN or target 
ACD DN. 


TOF operation with Interflow 


1 


A call attempts to enter a source ACD DN high-priority or non-priority 
queue that is in Interflow state. 


The Interflow destination is an ACD DN and the incoming call 
interflows to it. The call remains there until answered, abandoned, or the 
TOFT from the source expires. 


When the timer expires, the call is recalled to the source TOF queue. 


The call can be answered by an agent in the source ACD DN or target 
ACD DN. 


Note: If the Interflow destination is not an ACD DN, the call is never 
recalled to the source TOF queue. 


As agents become available, calls are presented based on call priority and the 
HPQ prompt in LD 23. 
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When HPQ = Yes, the agent is presented with calls in this order: 


1 calls in the agent’s own TOF queue 
(These are both high-priority and non-priority calls.) 


2 calls waiting in the agent’s own high-priority queue 
calls from other TOF queues targeted to this agent’s queue 


4 calls waiting in the non-priority queue 


When HPQ = No, the agent is presented with calls in this order: 


1 calls in the agent’s own TOF queue 
(These are both high-priority and non-priority calls.) 


2 calls from other TOF queues targeted to this agent’s queue 
3 calls waiting in the agent’s own high-priority queue 
4 calls waiting in the non-priority queue 


Empty queues 


Only when the source TOF queue, high-priority queues, and target TOF 
queues are empty is the agent presented with a call from the non-priority 
queue. 


If the non-priority queue is empty, the agent is linked to the available agent 
queue. 


Source TOF queues are searched first by priority then by time to find the next 
call to be served. All high-priority calls are answered before non-priority calls 
regardless of how long they have waited. If the priorities are equal, the oldest 
calls are serviced first. Refer to the flow chart in Figure 11. 


Time Overflow does not occur during the following conditions: 
— ACD Ring Again calls 

— Call Park Recall calls 

— callers active in Telset Messaging 

— calls to a source ACD DN in night service 


— when the target queue is in night service 
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Time Overflow Timer 

Incoming calls can Time Overflow only if the source ACD DN has a TOFT 
defined. However, an agent can still answer TOF calls as the target DN for 
another ACD DN. 


If the TOFT is defined, but the ACD DN is not configured as the target DN 
for any other source DN, the agents can only answer TOF calls from their own 
TOF queue. 


— Each target ACD DN can answer TOF calls for up to six source ACD 
DNs. 


— Each target ACD DN can answer TOF calls for up to 100 source ACD 
DNs when Enhanced Overflow is allowed. 


— Usually, it is not feasible to allow calls from a source ACD DN in one 
application to be answered by target ACD DN in another application. 


Note: Ifthe source ACD DN sends calls to a target ACD DN without the 
TOFT designated in LD 23, the source ACD DNs calls have high priority 
and get answered first. If the target ACD DN has the TOFT programmed 
in LD 23, its own TOF calls have priority over any calls sent by TOF. 
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Figure 11 
Call presentation to available agent 
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Compare with Automatic Overflow 


Automatic Overflow diverts a call to a Target ACD DN when the number of 
calls in the source queue meets or exceeds the Overflow Threshold (OVTH). 
The next call entering the queue attempts to overflow. For Automatic 
Overflow, the number of calls in the TOF queue must be added to the total 
number of calls waiting for service when a new call comes in. 


Table 9 shows a comparison between Automatic Overflow and Time 
Overflow. 


Table 9 
Overflow comparison 


Automatic Overflow Time Overflow 


Condition The number of calls waiting is greater The time the call waited is greater 
than the OVTH for the source queue. than the TOFT for the source queue. 


Action Put the call into the high-priority Put the call in the TOF queue for the 
queue, or non-priority queues for a source ACD. 


target ACD DN, if available. 


Result The call is answered by an agent in The call may be answered by an 
the queue where the call terminates. agent of the source ACD DN ora 
Only looks once at targets and if none target ACD DN. 
are available, the call is linked to the 
source ACD DN. 
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Automatic Overflow only 


In this configuration (see Figure 12), a call automatically overflows to a 
target ACD DN based on the number of calls in the source and target queues. 
It can only be answered by an available agent of the target DN. To 
Automatically Overflow, the following conditions are required: 


— A TOFT value for this ACD DN is not defined. 
— An Overflow destination must be specified. 


— The OVTH has been met or exceeded. 


Figure 12 
Automatic Overflow only 


Target 
queue agent 


1. Call attempts to enter Source queue. 


2. Call automatically Overflows into Target queue. 


3. Call is answered by an agent of the Target queue. 


553-1331 
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Time Overflow only 


In this configuration (see Figure 13), the call overflows by time to the Source 
queue and is answered by any available agent in the source ACD DN or any 
one of the three target queues. For a Source queue to Time Overflow only, the 
following conditions must be met: 


— The TOFT value must be set between 2 and 1800 seconds. 


— The OVTH must be set to a value of 1—2047. If set to 2047, the source 
queue does not Automatically Overflow. 


— The Overflow destinations must be specified. 


If an ACD queue is a TOF target but does not Overflow its own calls, the 
TOFT should be set low to ensure its own incoming calls will be answered. 


Figure 13 


Time Overflow only 


Source 
queue 


Source Target 
queue agent queue agent 


1. Call enters the Source queue. 
2. The call may Time Overflow while in the Source queue 
and be answered by an agent of either the Source or 
Target queues. 
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Automatic Overflow and Time Overflow 


This configuration is shown in Figure 14. When the source ACD DN is 
configured to Automatically Overflow and Time Overflow, a call could 
Overflow to a Target queue and be recalled back to the Source queue. This 
same call is then placed in the source TOF queue, and is answered by an agent 
of either the Source or Target queue. To Automatically Overflow and Time 
Overflow, the following conditions must be met: 


— TOFT must be set between 2 and 1800 seconds. 
— Specify the Overflow destinations. 
— OVTH value must be met or exceeded for the source ACD DN. 


— The BYTH of the target queue has not been met. 
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Figure 14 
Automatic Overflow and Time Overflow 


Source 
queue 


3 


Source Target 


queue agent queue agent 


A call may enter the Source queue. 
OR 
The call may Automatically Overflow into the OVDN queue. 


The call may be recalled back to the Source ACD DN 
and be placed in the Source TOF queue. 


The call is answered by an agent of either the Source 
or Target queue. 
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Interflow only 


Figure 15 shows Interflow by count only. In this configuration a call 
interflows by count to an IFDN that is an internal ACD DN. The call can only 
be answered by an available agent of that ACD DN. For Interflow to occur, 
the following conditions must be met: 


— IFDN destinations must be specified. 


— Interflow must be enabled either automatically (AENI) or by the 
supervisor’s ENI key. 


— The OVTH must be met or exceeded. 


— No Overflow destinations are available. 
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— The TOFT is not defined. 
— The IFDN queue is in day service. 


Figure 15 
Interflow by count only, answered by IFDN 


Source Interflow 
queue queue 


IFDN 
queue agent 


1. Call attempts to enter the Source queue. 
2. Call Interflows into the Target queue. 


3. Call is answered by an agent in the IFDN queue. 
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Interflow and Time Overflow 


Figure 16 illustrates Interflow and Time Overflow. A source ACD DN can be 
configured to Interflow as well as recalling to source by time. The IFDN must 
be an ACD DN. The call is eventually answered by an agent of the source 
ACD DN or Target queues. For this to occur, the following conditions must 
be met: 


— The IFDN must be defined as an ACD DN. 


— Interflow must be enabled either automatically (AENT) or by the 
supervisor’s ENI key. 


— The OVDNs must be defined. 

— The OVTH must be met or exceeded. 
— The BYTH must be met or exceeded. 
— The TOFT must be defined. 
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Figure 16 
Interflow and Time Overflow 


1 Source 
— queue 


Source Time Target 
queue agent Overflow queue agent 


. A call may enter the Source queue. 
OR 
. The call may Interflow into the FDN queue. 


. The call may be recalled back to the source ACD DN 
and be placed in the Source TOF queue. 


. The call is answered by an agent in either the Source or Target 


queue. 
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Feature interactions 
Display Waiting Calls (DWC) key 
A Display Waiting Calls key can be assigned to a supervisor position for each 
ACD DN. The lamp state of the Display Waiting Calls (DWC) key 
corresponds to the lamp state of the Calls Waiting (AWC) key. This gives the 
supervisor an indication of when to use the Interflow (ENI) key. A maximum 
of eight DWC key appearances per queue are allowed. The Display Waiting 
Calls key shows a count of calls waiting that includes all calls in queue that 
have not been presented to an agent. 


The information on the Display Waiting Calls key is updated every time the 
key is pressed. 
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When the DWC key is used, the display on the telephone follows this format: 


aaa—bbb—ccc—ddd 


Legend: 
aaa 
bbb 
ccc 
ddd 


= all calls in queue 

= number of positions occupied for that ACD DN 

= waiting time for the oldest call in queue 

= number of TOF calls aimed at the Source ACD DN queue, the 


sum of all calls that could flow into that Source queue 


The ddd field indicates how many calls are in other TOF queues that target 
this ACD DN. The ddd field does not include the number of TOF calls in its 
own queue because that amount is already included in the aaa field. Figure 17 
shows DWC display examples. A ddd of zeros indicates one TOF call is 
aimed at this ACD DN from another queue. 


Figure 17 
DWC display examples 


Meridian Digital Telephone alphanumeric display 
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To determine the actual number of TOF calls in any source queue, the 
supervisor presses the Display key, octothorpe (#), followed by an ACD DN. 
The system displays how many calls that ACD DN has in its TOF queue. 
Supervisors can see how many calls are in their own TOF queue by entering 
their own ACD DN. Figure 18 shows the display comparisons. 


Figure 18 
Display comparison 
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Calls Waiting Indication 

The Calls Waiting Indication (AWC) lamp on the agent position informs the 
agent that the number of calls in the queue meets or exceeds a threshold value, 
and the call handling rate should be increased. The light states on these keys 
are used to indicate different conditions relating to Automatic Overflow. 


With TOF, the lamp states include this ACD DN’s TOF queue when counting 
the number of calls waiting. These lamps have four states: 


— Dark The calls waiting in this ACD DNs high-priority, non-priority, and 
TOF queues are less than the Call Waiting Threshold (CWTH). 


— Steadily lit The number of calls waiting in the high-priority, 
non-priority, and TOF queues equals or exceeds the Call Waiting 
Threshold (CWTH) or the Call Waiting Lamp Flash (CWLB), but is less 
than the Busy Threshold (BYTH). This ACD DN can receive Automatic 
Overflow calls, as in normal operation. 


— Fast flash Some calls are waiting and may be overflowing to another 
ACD DN. The total number of calls waiting meets or exceeds the 
Overflow Threshold (OVTH) or the Call Waiting Lamp Wink. When an 
ACD DN is in this Overflow state, all new incoming calls are diverted to 
a Target queue, if one is available. 


— Flash The number of calls waiting in the high-priority, non-priority, and 
TOF queues meets or exceeds the Busy Threshold (BYTH) or the Call 
Waiting Lamp Flash (CWLP), but is less than the Overflow threshold 
(OVTH). The ACD DN cannot receive Automatic Overflow calls from 
other queues. 


ACD Ring Again 

Ring Again allows an internal telephone call originator to have on-hook 
queuing. A special ring-back tone is returned before RAN or Music is played. 
When the Ring Again key is activated, the call is placed in the queue and the 
originating telephone is then free to make and receive other calls. Only 
internal calls can activate Ring Again. 


When Ring Again is applied to a call, that call is not eligible for Time 
Overflow. 
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Call Park 


Calls parked by agents are not eligible for Time Overflow. However, if a 
target agent parks a call after Automatic or Time Overflow, it recalls back to 
the target agent who parked it, if available. If the parking agent is not 
available, it recalls to the Source queue. 


Call Party Name Display (CPND) 

This feature operates on telephones with alphanumeric display with CNDA 
Class of Service only. When a target agent answers a TOF call, the originating 
DN or Trunk Access Code displays, as well as the source DN and name. The 
originating telephone display shows the CPND name associated with the 
terminating telephone. 


ACD Call Supervisor 

If an agent answers a TOF call and then presses the ACD Call Supervisor key, 
the agent is connected with the assigned supervisor, and not the supervisor of 
the overflowed queue from which the TOF call was directed. 


Dialed Number Identification Service (DNIS) 

When a DNIS call is presented to an agent with display, the source ACD DN 
and DNIS number are displayed with the trunk Access Code (ACOD) and 
member number of the originating party. 


Display 

When a target agent answers a TOF call, the source ACD DN is displayed 
following the originating DN or Trunk Access Code. If the originating 
telephone has display, it shows the dialed (source) DN, the ACD DN, and the 
agent for the terminating agent position. 


When Call Forwarding All Calls, a call is forwarded automatically and can 
still Time Overflow to a target ACD DN. The originating display shows the 
dialed DN and the final terminating DN. 
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ACD Message Center 

An ACD Message Center is an ACD agent specially equipped with Message 
Indication (MIK) and Message Cancellation (MCK) indicators. When a call 
comes into the ACD Message Center it lights the MIK lamp. The agent 
answers the call and writes down the message. 


By pressing the MIK key while on the call, the Message Center agent 
activates the Message Waiting (MWK) lamp on the originally dialed 
telephone. When that telephone user presses the MWK key, it lights the 
Message Center agent’s MCK indicator. After delivering the message, while 
still on the call, the Message Center agent presses the MCK key to turn off the 
telephone user’s Message Waiting indicator. When a call to the Message 
Center agent time overflows, it can be answered by any of the Target queues 
defined for that telephone. 


— An Integrated Message Center (IMS) is similar to the ACD Message 
Center in the operation and function of the MIK, MCK, and MWK 
key/lamp pairs. When a call going to an ACD DN with IMS applications 
time overflows, the call can be answered by any agent in the Target 
queues. 


— The Integrated Voice Message System (IVMS) operates much the same 
as IMS. Within the IVMS environment, if a call to an ACD DN time 
overflows, it can be answered by any agent in the target queues. It is 
recommended that IVMS ACD DNs also have target DNs within the 
IVMS environment. 


— Telset messaging is supported by IMS/IVMS applications. While a call 
is active in Telset Messaging, it remains in the queue working up to the 
front of the queue. However, that call is not eligible for answering by an 
agent even if it is in the front of the queue. When Telset messaging is 
complete, the queue timer for that call is reset because the call was 
unavailable for ACD service. 


— Acallin the low-priority queue active in Telset messaging is not eligible 
for Time Overflow treatment until after Telset Messaging is complete. 
The TOF Timer is reset when the caller dials “0” to signal the caller is 
now available for ACD service. Calls in the high-priority queue are not 
eligible for Telset Messaging. 


Note: Calls in the TOF queue are not eligible for Telset Messaging. 


ACD Feature description 


Page 240 of 278 


System features 


Multi-Tenant Services 

Sites with Multi-Tenant services and Overflow must have source and target 
agents assigned the same tenant number. If they are not, an agent may be 
presented with an unanswerable call. Because Time Overflow calls are not 
put into target queues but can be presented to target agents, an agent can be 
presented with an unanswerable call. The call is unanswerable because target 
agents cannot answer a call arriving on another tenant’s trunks. 


Night Service Treatment 

When all agents for a particular ACD DN activate the Make Set Busy (MSB) 
key, or the supervisor activates the Night Service (NSVC) key, that ACD DN 
is in the Night Service Mode. When a queue is in Night Service, the following 
interactions apply: 


— Calls in the TOF queue: 
A TOF call can be answered by one of the target ACD DNs or routed for 
regular Night Service treatment, whichever comes first. 


— Calls in high-priority or non-priority queues: 
Waiting calls that are not in the TOF queue receive Night Service 
treatment defined for the source ACD DN. If a call overflows by count 
into the Target queue, and the source ACD DN goes into Night Service, 
the call does not Time Overflow back to the source ACD DN. 


— New calls to the queue: 
New incoming calls are redirected for Night Service treatment. If Night 
Service is not defined, the calls are not eligible for Time Overflow. 


Recorded Announcement (RAN) 

When a call overflows by time or count to a target ACD DN, the RAN or 
Music specified for the source ACD DN remains in effect for all overflowed 
calls. With First RAN On Arrival enabled (FROA = YES), the RAN is 
connected when the call enters the queue. When FROA = NO, the RAN is not 
sent out until the First RAN Timeout (FRRT) has expired. Refer to X// 
features and services for additional information on RAN. 
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Operating parameters 


The Time Overflow Timer (TOFT) must be defined to give calls overflow 
treatment into the timed queue. However, an agent can still answer TOF calls 
as the target DN for another ACD DN. Incoming calls can be given Time 
Overflow treatment only if the source ACD DN has a defined TOFT. 


If the TOFT is defined but the ACD DN is not configured as the target DN 
for any other source DN, agents can only answer TOF calls from their own 
TOF queue. 


Each target ACD DN can answer TOF calls for up to six source ACD 
DNs. 


With Enhanced Overflow, each target ACD DN can answer TOF calls 
for up to 100 source ACD DNs if NACD is allowed. See Network ACD 
description and operation (553-3671-120). 


It is not recommended to allow calls from a source ACD DN in one 
application to be answered by target ACD DNs in another application. 


Engineering guidelines 


The following guidelines are recommended for database configuration and 
should be followed to make this feature operate as effectively as possible. 


All agents should have a Class of Service (CLS) that allows the agent to 
receive incoming calls (UNR, TLD, CTD, CUN, SRE). 


All agents within the same ACD DN should have the same tenant 
number. 


All agents belonging to the same target ACD DN should have the same 
tenant number as the source ACD DN. 


Data administration for TOF is provided in the X71 input/output guide. 
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